On Wed, Feb 15, 2012 at 10:35 PM, Keshav Kini <keshav.k...@gmail.com> wrote: > 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.
Sure, that could make sense. >> 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. But for everything not part of the upstream packages, licensing shouldn't be an issue. > 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). Or we just have one repository--I'm still not seeing any advantage of having multiple repos (and many disadvantages). > 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. Being able to uninstall things, or switch between versions, would be really nice but is somewhat orthogonal. (And yes, we could borrow infrastructure here.) > 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? This is information that should be in the revision control, ideally switching spkgs as part of the same commit (set) as any modification to the library or scripts. The repo would be the base + library + spkg metadata (what upstream tarball + modifications + custom installation scripts). - Robert -- 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
