Robert Bradshaw <rober...@math.washington.edu> writes: > On Thu, Feb 9, 2012 at 7:53 AM, Jason Grout <jason-s...@creativetrax.com> > wrote: >> You correctly interpreted my response, and I agree with your conclusions. I >> haven't used the sage branch-handling code in years. > > I used them extensively when (1) I was working on my thesis, and > wanted a set of patches (possibly corresponding to several tickets) > separate from my other development and (2) when working on coercion, > where rebuilding all the Cython code was painful if I pushed/popped a > patch touching parent.pxd and (3) to have a pristine base on which to > referee tickets (without having to disturb anything else I'm working > on). I suppose some people simply have multiple copies of Sage itself > lying around...
Right, this is exactly the use case I came up with when trying to think why people might use "Sage branches" - avoiding Cython recompilation. Your first point I assume also includes avoiding Cython recompliation, otherwise you could just be using multiple Mercurial queues in a single "Sage branch" (though certainly `hg qq` is not the friendliest thing). > Another important user, though this could be handled as a special > case, is the patchbot. It creates a new "symlink branch" for each > ticket, and when re-visiting a ticket it doesn't have to > re-apply/rebuild except for what changed. As rebuilding is cheaper > than testing for most changes, I suppose we could throw away this work > every time, but it was a precursor to the next phase of the patchbot > which would be a sage notebook server that would allow you to start > worksheets in any one of the branches (simultaneously) to actually > play with the code. Right, I'd certainly not advocate throwing away these advantages. I just don't think that Sage itself should be aware of these branches. The symlink should be handled / changed by a separate helper script of some kind. > Perhaps, with some agressive caching mechanisms like ccache, we could > do this cloning at a higher level (and then then handle spkgs in the > patchbot as well). This would fit in well with the vision of having a > single top-level repository that contains everything except the > pristine upstream source tarballs, and "installing" an spkg is a > matter of submitting a patch to change a reference and re-building. Well, considering among other things the recent discussions about licensing, I don't think that it's going to be possible to have a single top-level repository for all Sage code. I think ideally we should have three repositories, one for the Sage library (what is currently in $SAGE_ROOT/devel/sage-main), one for Sage packages (an aggregation of the repositories in all our current SPKGs, basically), and one for the Sage base system (an aggregation of the scripts repo and the root repo). Note that the above is basically what Burcin has implemented in lmonade, with the exception that he uses ebuild files from the sage-on-gentoo project in place of our homegrown spkg-install scripts. IMO this is definitely the way to go for Sage in the long run. SPKGs are too free form to allow us to really maintain a Sage installation without bitrot of some kind - for example, we cannot uninstall SPKGs, whereas in lmonade you can uninstall the equivalent ebuilds. Related question: do we actually have a record of what versions of what SPKGs were released with what versions of Sage? For the standard SPKGs you can just look into the directory in the Sage tarball, but what about optional packages? -Keshav ---- Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
