On 03/10/2016 03:23 PM, William Stein wrote: > > Could you say more? (I mean about what you might imagine Sage could > do to improve -- both incrementally or dramatically?) I'm sure > everybody really appreciates your experience, and speaking up about > this here. >
Oops, I wrote a book: Dramatically, I really like Burcin's lmonade project. It keeps the "one big download, everything just works" model, but instead of using a Sage-only package manager with Sage-only packages, it reuses the existing Portage package manager and the Gentoo package repository. You can install it without admin rights, and upgrades are easy. And most importantly, Sage developers don't have to worry about building and installing GCC and all of the other necessary evils -- Gentoo developers do it. But incremental improvements have more to offer. I think the single best thing you could do for Sage's popularity is make it installable with "emerge sage", "apt-get sage", "yum install sage", or "brew install sage". Users might get a version that's a month old, and they might wind up with a minor version of gap that you have not personally tested, but wow is that better than having to try to explain how to build Sage to a seventy-five-year-old guy from another continent. On Fedora, Debian, Gentoo, and derivatives that should be possible, and it is happening slowly. We're no longer patching everything that we use. We have a ./configure script. Work is being done to pick up system packages where possible (http://trac.sagemath.org/ticket/20137). If configure.ac evolves to have a complete list of dependencies and to search the system for them, that will be a huge hurdle cleared. With it gone, the Linux distributions will finally be able to package Sage, and I think most of them will. You already have Debian/Ubuntu, Fedora, and Gentoo people interested. For OSX, I hear homebrew is the best option. Slowly we can create homebrew packages for all of Sage's dependencies, and finally for Sage itself. (Unfortunately, OSX access is needed to do most of that work). But in the meantime, the existing build system can remain as a fallback. Once everything has been packaged, "brew install sage" should work flawlessly for OSX users as well. That covers basically everyone who is building Sage right now. And I can even suggest it to people that I don't want to spend hours helping. After that work has been completed, the spkgs and sage-install could go. Updating a Sage depencency at that point will involve a one-line change to configure.ac, and maybe an update to a homebrew package (depending on how much of that burden we take on). Windows users get a VM, same as always, unless someone knows how to package things for Cygwin. We can still offer big binary packages -- that doesn't have to change -- but building from source should be as easy as building the Sage python library. You can get all of the dependencies installed easily by installing Sage with your package manager. If you want to modify one of Sage's dependencies, that should be possible -- just make your change in the upstream project and `make install` it to /usr/local which will then be picked up when you rebuild the Sage library. What about the failing tests due to outdated dependencies? If there's a bug in Sage due to a bug in an upstream project, I think we should add the test case to the upstream project instead of our doctests. That way if we upgrade the Sage library and not libfoo, the doctests don't start failing. This isn't critical because most end users won't be running the tests (we make it possible on Gentoo, though). Anyway, the best laid plans and all that. Some or all or none of that could go awry. The first step is to make it possible to use system libraries instead of building another copy of everything I already have installed. Once that's done... life finds a way. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
