Skip to content

Easy installation of a git repo with a package.py in the root #1136

@DavidPoliakoff

Description

@DavidPoliakoff

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

  1. Pythonic, spacky implementation of this bash script (perhaps through a new verb, spack clone)
  2. Dependency handling. How can my repo depend on another repo? Perhaps syntax like (depends_on(get_github_package("[github URL]"))
  3. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions