On Thu, Feb 16, 2012 at 3:32 AM, Keshav Kini <keshav.k...@gmail.com> wrote: > Robert Bradshaw <rober...@math.washington.edu> writes: >>> 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'm referring to William's comments that the Sage library should be > shipped under a different license from the Sage distribution as a whole > (GPLv2+ and GPLv3+ respectively). I guess it's still possible to ship > them together as a whole, though.
It's the upstream spkgs that are GPLv3+, not any of the Sage code. > But considering that we might one day want to make part of the Sage > library possible to install into your system Python distribution > (right?), it might be a good idea to keep it separate from the > "infrastructure" part of Sage. While that's a nice idea, there's much bigger technical hurdles to overcome than repository structure. >>> 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). >> >> [...] >> >> Being able to uninstall things, or switch between versions, would be >> really nice but is somewhat orthogonal. (And yes, we could borrow >> infrastructure here.) > > I think there are some advantages to keeping our package management > separate from our mathematical library separate from our glue which > binds the two together, namely that we can import the first (from > Gentoo Prefix, say) and export the second (as a standalone Python package > with optional dependencies on stuff which we currently depend on, say). If the sage library could be used a s a standalone Python package, and we could use Gentoo Prefix as is (with no modifications, but requiring it as a dependency(?)) this might make more sense. I see the "glue" code as being part of the library, neither is of much use without the other. > Honestly I'm not sure how likely it is that the Sage library might one > day be separable from Sage, but I've heard people say that it is a > long-term goal. If that's not the case, we could consider it part of the > glue (i.e. bundle it with the scripts and root repos), but I still think > that we should keep the packaging subsystem separate to allow us to swap > in other stuff like ebuilds for Gentoo, .deb packages for Debian/Ubuntu, > etc., to keep open the prospect of one day finally being able to ship > something that's not monolithic. > > Or maybe the long-term picture of Sage is going to turn out to be a > VirtualBox VM on all platforms. Who knows... I think Sage will be monolithic and Windows be VM for the near future at least, with a larger percentage of people using a Sage install "in the cloud" on a university or otherwise hosted server for the near-mid term future. But as you said who knows... >>> 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). > > I'm not sure that's such a good idea. We should be able hotfix SPKGs > without having to hotfix Sage itself. Or to put it another way, the > development of build scripts for packages shouldn't really be in > lockstep with the development of Sage, the mathematical system, since we > have no control over upstream releases or bugfixes. Note that we don't maintain the actual build script for most upstream packages, unless there's something Sage-specific. Currently, spkgs are pristine upstream tarball + Sage customizations + metadata (e.g. contact information). Ideally, the customizations is empty, but not always. The question is where to put these customizations. Currently, they're in a separate repository for each spkg (which is also separate form the upstream project's repo). We push this upstream when it makes sense, but even when we can it's often a slow process. Often changes here (including bumping the version) involve a parallel set of changes to the library (though this need not always be the case, especially for the more stable/standard spkgs). Being able to do this actually helps with the lack of control over upstream releases and bugfixes. Where would you propose we stick this information? > I see a future build-script repository as being something that people > continually update from trunk to "check for updates". To avoid premature > upgrading to new SPKGs that don't work with an old version of Sage, the > Sage package itself would require certain versions of certain SPKGs and > no higher. Of course, they would not pull from the Sage repository > itself until an actual version was released. This is more or less how > many Linux distributions work, i.e. package metadata / build scripts / > etc. are updated constantly, and actual software packages have much more > infrequent stable version releases. This assumes the various packages can be upgraded independently, which is clearly not the case. > So for this to work the Sage repository would have to be separate from > the packages repository. But for this to work we would need a separate pari-sage, separate from pari, in the global package repository if we made any modifications to pari. Lets assume for the moment that the glue+python library is a single repository called "sage-lib." From what I gather, what you want the sage distribution to be is: package_manager (e.g. gentoo-prefix, a prerequisite) mpir-x.y.z pari-x.y.z cython-x.y.z python-x.y.z ... sage-lib-x.y.z Where sage-lib-x.y.z lists as its dependencies mpir-x.y.z pari-x.y.z cython-x.y.z python-x.y.z ... Right? Then the package manager would just do its thing. The crux of the issue is that what we really have for the dependencies of sage-lib-x.y.z is mpir-x.y.z pari-x.y.z + epsilon cython-x.y.z + epsilon python-x.y.z ... What I would like to see is the dependencies (epsilon's and specific version numbers) stored in the single repository with the code that depends on them, so a commit could describe a global sage state and all development could be expressed as "just a (set of) patches (= branch in a personal/public repo)" Changing this file would trigger a re-build (ideally with lots of transparent caching). That in a nutshell is my proposal. Currently the epsilons are scattered across various non-upstream repos, there's no explicit history of versions outside of what happens to ship in a release tarball, and there's several distinct repos for the various pieces of Sage. I think we can do better. > Another advantage of this is that people writing their own packages to > use with Sage could more easily and quickly get their stuff into the > Sage package repository as an official optional package, which goes well > with what William (?) was saying somewhere on sage-devel recently about > how the packaging system of Sage should allow people to write their own > packages without communication with us. Though of course those people > could always distribute files that would plug into our packaging system, > having the package repository separate from Sage would also encourage it > to be modular enough to make this feasible. Certainly a requirement to having a system that supports optional spkgs. Sharing an optional spkg would be as simple as sharing a patch (or just the new files themselves, which contains a pointer to the upstream package and any needed metadata) and rebuilding. Upgrading to a newer version of an upstream package would likewise be just a patch as well. > Just some thoughts. And very good food for thought. - 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
