> > > > For each spkg, there would be a corresponding directory containing the > > > > spkg-install script and the sage subdirectory (but _not_ the source > > > > code for the package itself). I think it would be a good idea to > > > > create a format for the spkgs that is a little more standardized. > > > > Here is an example: > > > > > > > > ipython-0.8 > > > > spkg-install # existing spkg-install script > > > > ./spkg-patches # rename the sage directory to this for clarity > > > > spkg-fetch.py # a python script that could be called to > > > > get the source for ipython > > Would spkg-fetch.py download package A from A's homepage or from sage.math?
I think the best approach would be to have spkg-fetch.py download package A from A's homepage. Patches would be kept in the spkg repo and applied by the spkg-install script upon building. In many ways this is very similar to gentoo = original source + patches -> build -> install. > > > > > > > > I think the spkg-fetch.py script is an important part of this. It > > > > would allow us to not include the source code for each package in the > > > > repo, but it would make it very easy to write a script that begins > > > > with only the scripts in the repo and builds a full source > > > > distribution of everything. > > I think this penalty could be paid once - the source packages could be > > downloaded into the hg tree - but not commited to the repo. Once that > > is done, the spkgs could be built in place. > > > > My thought is that the only people who would have to do this are those > > who are maintaining/creating spkgs. Most people will simply use the > > created spkgs that include the source. > > So if I download sage-version.tar, it would have the spkgs with their > sources. If I ran sage -upgrade, it would do an hg checkout on the > spkg/standard directory, update any spkg that needs to be and download > (if necessary) the sources to build and compile them. Did I get that > right? Almost. The first part is right - the full sage tarball would have all the spkg stuff and the package sources - just like it does today. But, sage -upgrade could work two different ways: 1. If you just want to get the latest stable version, it would download the newest spkgs (that contain the full source) and install them. This assumes that someone (the maintainer or the spkg) has used the spkg hg repo and the spkg-fetch.py script to create an updated spkg. But the important point is that most users won't see anything different from the current approach - they always deal with the full spkg with the package source. 2. For people who are doing lots of spkg development, we could make something like sage -devel that does what you describe - it would use the hg repo, download the source, create a new spkg and install it. The first parts of this process (creating the spkg) would be exactly what developers do to create a new spkg. Does that make sense? > didier > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
