On 5/31/07, didier deshommes <[EMAIL PROTECTED]> wrote: > > On 5/22/07, Brian Granger <[EMAIL PROTECTED]> wrote: > > > > SAGE developers, > > > > As you may know, I have been working on building some new spkgs and > > have also begun refactoring the spkg build scripts themselves. A few > > ideas that I would like feedback on: > > > > 1. Creating a repository for the spkg makefiles and build scripts > > +1 > Ideally, I would like having a full hg repository for the spkg > makefiles *and* the source. I have had to patch close to 10 packages > this past weekend and I need to eventually submit patches for all of > them. Having an hg repo for these would make the process much more > easier.
I have gone back and forth about whether to include the source code for the packages themselves. One problem is that some of the sources (like qt and enthought) are really big (probably 100s of MB). Another problem is that I absolutely don't want to get into the business of forking projects. While in certain cases SAGE has done this with good success, overall I think it should be avoided at all costs - mainly because forking a project requires a potentially large amount of effort. I think the preferred way of working shoud be for people to work with the developers of the actual projects to commit patches directly to the projects themselves. That way, the packages in spkg can be as close to possible unpatched versions of the original source. This doesn't answer the question of how to maintain those patches, that don't get sent back upstream. This definitely needs to be addressed. > But I would settle for a sage/spkg-patches.txt file that one could > edit and keep track of under an hg repository. Some kind of version > control on packages is necessary. Definitely. > > 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 > > > > 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. > > > > Some questions about this approach: > > > > Does this seem like the best way to manage the spkg infrastructure? > > +0 > The only problem I see with this is the initial cost of checking out > all these packages from sage.math 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. I agree it is sort of a pain - but imagine if the hg repo had all the sources for the projects. Then the hg repo could be many 100s of MB itself. I think that is the best reason to not put the project sources into the repo. More thoughts? > > > --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
