Hey @citibeth @trws @adamjstewart
We were talking about this yesterday (#1108) . Bower lets you do the following
bower install [github link]
It pulls a package.json out of the given repository and installs the dependencies and the package itself. This leads to a turnaround from "I see a project that interests me" to "I have this package installed for my project" on the order of five minutes. The spack equivalent is to... spack edit -f [desiredPackageName] and copy and paste from the github repo? In the absence of this feature, I'll be polishing up a bash script for this purpose (do not run this under any circumstances, it hasn't been vetted and I can think of ways to make it delete things you wouldn't want deleted)
#!/bin/env bash
echo $tarball
curl -L $1/tarball/master | tar -xz */package.py
#name of the downloaded package
packagename=$(grep "class.*Package" */package.py | sed "s,class ,," | sed "s,[(].*,,")
#name of the folder I get from github
foldername=$(ls -d */)
mv -f $foldername $packagename
#make a package folder
mkdir ../var/spack/repos/builtin/packages/$packagename
#move the package into that folder
mv -f $packagename/* ../var/spack/repos/builtin/packages/$packagename
rm -r $packagename
#install it
spack install $packagename
(Run from a specific directory) I can point this at my test repo (https://github.com/DavidPoliakoff/trivial), whose only interesting feature is having a package.py in the root, and it will pull the package file out of the repo, make a directory for it in my spack repo, move the package.py into that directory, then install it.
This is a horrible way of achieving the goal, but it's what I'll use in projects I don't feel like putting up package PR's for until
spack [verb] [github link]
lets me install the contents of that repo using spack, using a package.py provided by that github repo. Essentially, this lets me turn the spack model on its head, instead of $SPACK_ROOT/var/spack/repos/builtin/packages/ being the place that says what packages exist, software packages can provide a description of how they should be packaged by spack, and commands can be run to pull them down.
TODO's would be
- Pythonic, spacky implementation of this bash script (perhaps through a new verb, spack clone)
- Dependency handling. How can my repo depend on another repo? Perhaps syntax like (depends_on(get_github_package("[github URL]"))
- Doing the same for hg, svn, tarballs
Basically, Spack wants to have a repo (or set of repos) that tell it where software exists, and how to pull it down. This is a great model, but I also want software to be able to say "here's how Spack can install me" and have Spack be able to respond
Hey @citibeth @trws @adamjstewart
We were talking about this yesterday (#1108) . Bower lets you do the following
It pulls a package.json out of the given repository and installs the dependencies and the package itself. This leads to a turnaround from "I see a project that interests me" to "I have this package installed for my project" on the order of five minutes. The spack equivalent is to... spack edit -f [desiredPackageName] and copy and paste from the github repo? In the absence of this feature, I'll be polishing up a bash script for this purpose (do not run this under any circumstances, it hasn't been vetted and I can think of ways to make it delete things you wouldn't want deleted)
(Run from a specific directory) I can point this at my test repo (https://github.com/DavidPoliakoff/trivial), whose only interesting feature is having a package.py in the root, and it will pull the package file out of the repo, make a directory for it in my spack repo, move the package.py into that directory, then install it.
This is a horrible way of achieving the goal, but it's what I'll use in projects I don't feel like putting up package PR's for until
lets me install the contents of that repo using spack, using a package.py provided by that github repo. Essentially, this lets me turn the spack model on its head, instead of $SPACK_ROOT/var/spack/repos/builtin/packages/ being the place that says what packages exist, software packages can provide a description of how they should be packaged by spack, and commands can be run to pull them down.
TODO's would be
Basically, Spack wants to have a repo (or set of repos) that tell it where software exists, and how to pull it down. This is a great model, but I also want software to be able to say "here's how Spack can install me" and have Spack be able to respond