On Wednesday, May 4, 2011 10:51:10 AM UTC+2, Burcin Erocal wrote: > > Hi Dag, > > On Wed, 4 May 2011 00:51:56 -0700 (PDT) > dagss <d.s.se...@astro.uio.no> wrote: > > > I don't really have a say in this, but I've given this a lot of > > thought since I decided to drop Sage as my scientific Python > > distribution a year ago and have been searching for a new one ever > > since. > > > > My problem with Gentoo in general is that it solves the problems that > > SPKGs have by adding complexity (in the same way any Linux distro > > does). > > > > I much prefer something like Nix (http://nixos.org), where Eelco > > Dolstra instead had a new, brilliant idea which just makes simple > > things powerful. I wrote these notes up on using Nix for a scientific > > Python distribution (including Sage): > > > > https://github.com/dagss/scidist/blob/master/ideas.rst > > > > (I may be interested in putting in work in this direction...) > > Robert posted a link to your notes here at some point. I also saw the > thread on the gentoo-alt mailing list where you asked about using > prefix for a scientific software distribution. Especially after reading > your notes, I seriously considered using Nix as well. > > Nix is based on a beautiful idea, but it doesn't really reduce the > complexity. We want more features from the build system, this will > naturally add complexity. When I first started out using Gentoo, I > thought it was a beautiful and simple extension of the BSD ports system. >
What I mean is that you still have to do things like 1) tell make to install to temporary location, 2) scan for list of files, 3) record list of files for future uninstall, 4) move the files to final location. With Nix this sort of thing just goes away. Of course, it's already thoroughly debugged, so complexity may not matter. > BTW, you could use the gentoo package manager to replicate a previous > version of your tree with using binary packages (you can make these > even after you are done installing the ebuild). There seems to be code > for something like this already: > > http://en.gentoo-wiki.com/wiki/Demerge > Yes, but AFAICT we're still talking at least half a minute for a rollback, and some hundred megabytes for creating a new branch. With Nix you can do both in less than a second. Very useful during development. And I really like the Nix idea that several people can completely safely share a nix store (and so share disk space + build time CPU). Think about the consequences for Sage development: 1) William gets a patch from Trac and tests it against a package on sage.math 2) Without knowing about this, you do the same, also on sage.math ...then Nix figures out that this derivation was already built and just uses William's build results. With Portage, do get this behaviour, William would at the very least have to register somewhere that he created a binary package corresponding to this trac ticket, and offer it for download. That requires you to create tools around that. With Nix, you just keep your existing workflow (use "patch" on your sources), and the cache kicks in more transparently. > But of course, Gentoo has a scientific community etc. etc. which Nix > > sort of lacks, so I can definitely see Gentoo making more sense for > > you. > > This is the strongest argument that makes Gentoo attractive. It > justifies the effort to switch to their package format. Since then, we > won't have to worry about manually updating spkg's ourselves. > > Francois is always reporting how a more recent version of a package > works perfectly with Sage. This is simply because Gentoo gives him > those packages for free on his sage-on-gentoo install. > Well, if he's running Gentoo as his Linux distro, that *greatly* reduces the problem in the first place. The main problem one must focus on here is that Gentoo packages (and nixpkgs for that matter) has strong assumptions in them that you use the whole system. If you want to use the host system toolchain, you get all kinds of problems, expected or unexpected. For instance, Gentoo prefix requires a more modern version of Bash than what is available on my Uni's computers. So Sage would need to (perhaps optionally after probing) build its own Bash, or it becomes impossible to install out of the box at my Uni. And Gentoo prefix patches their gcc as well -- although I did make a little bit of headway simply telling it to use the one of the system, that's still around where I stopped using Gentoo Prefix. Also I remember that Gentoo packages in general seems to like living on the bleeding edge of autotools, so probably that must be built as well. I remember seeing discussions on this list about whether "patch" should be shipped with Sage or not. Discussing going with Gentoo Prefix *really* puts that in perspective :-) Of course, if you either a) decide to turn Sage into a mini-OS, or b) only use Portage and don't care about compatability Gentoo packages you don't have this problem. Perhaps some compromise can be reached, but not, is my hunch, without added complexity and quirks. I'm sure you already know this, and also my information may be outdated as I last checked out Gentoo prefix a year ago. Anyway, this is the main reason I ended up proposing just "doing my/our own thing" (which is when you need simple&elegant technology). Anything coming out of the distro communities seem to have the assumptions that you should always use a distro for all your software. E.g., the Nix mailing list they explicitly told me to check out 0install or GUB for my purposes instead... IF you can get something working on Gentoo Prefix without lots and lots of work, I agree 100% that's the way forward at the time being, simply because there's no mature alternative at the moment. But if lots and lots of work is needed anyway, that's when you start to look at technical advantages/disadvantages. Dag Sverre > -- 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
