Re: [sage-devel] Re: Python as build-time dependency
On Sun, 12 Jan 2014 21:15:21 Volker Braun wrote: > At the risk of veering even further off-topic, I would like to give up > "tree relocation" as it is currently defined. Its cumbersome (need to check > that we haven't been moved all the time) and insecure. > > For relocatable binaries, we build with / rewrite rpaths to be relative and > make all libtool .la files have relative paths. This may require further > dependencies, like tools to rewrite rpaths. Also, once you unpack the > binary and start compiling further stuff in its directory it may or may not > be relocatable any more. But really the goal is to distribute binaries, not > allow you to move your sage directory around all the time. All modern > linuxes and intel OSX allow relative rpaths and its modification with the > help of special tools. > > On Monday, January 13, 2014 12:00:55 AM UTC-5, William wrote: > > Of course, relocation is really a way to solve the problem "build a > > sage binary once and make it available to other people to install in > > their home directory". I don't know of any other way to solve that > > problem. I also don't know if *any* of the non-Sage build systems in > > this thread support relocation of binaries. +1 and gentoo-prefix is not ready for making binary install. lmona.de probably should aim for that though. Francois -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On 01/12/2014 02:06 PM, Felix Salfelder wrote: > On Sun, Jan 12, 2014 at 01:09:42PM -0500, Michael Orlitzky wrote: >> Prefix is designed to run as an ordinary user on non-gentoo systems. If >> you're on gentoo, you don't need it (unless you don't have root). Plenty >> of us have been able to get it working, so if we made a concerted >> effort, I'm sure we could stick a nice UI on it. Besides, it's currently >> working better than the nonexistent rewrite being discussed. > > the nonexistant rewrite exists as a demo [1]. it is based on autotools > (not python). it is mostly boilt down to calling the spkg-install > programs in the right order, while being semantically similar to the > current toplevel makefiles and scripts. it also supports package content > lists (to possibly remove/exchange packages) and is able to optionally > completely disable packages (fallback to system packages). Sorry, your rewrite isn't the one to which I was referring. If we could not build an entire Linux distro from source just to run sage, that would be the holy grail. But I was only talking about rewriting the spkg installation stuff, which duplicates (poorly) exactly what Gentoo already does. > imo, sage should stay distribution independent, distributions other than > sage should only require to package sagelib in the end. and whatever > happens next, sage (the library) should be freed from hardcoded paths > and from package management code, so not everybody has to work that > out again and again, YMMV of course. Completely agree. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On 2014-01-12 20:06, Felix Salfelder wrote: On Sun, Jan 12, 2014 at 01:09:42PM -0500, Michael Orlitzky wrote: Prefix is designed to run as an ordinary user on non-gentoo systems. If you're on gentoo, you don't need it (unless you don't have root). Plenty of us have been able to get it working, so if we made a concerted effort, I'm sure we could stick a nice UI on it. Besides, it's currently working better than the nonexistent rewrite being discussed. the nonexistant rewrite exists as a demo [1]. I feel obliged to point out that most of your tickets implementing this either don't merge cleanly or break the build. I am a fan of autotools (In terms of build portability, absolutely nothing beats it). However, instead of trying to rewrite the Sage build system all at once, you should try to move in smaller steps which individually actually work (see for example #15580 for one such small step). Jeroen. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
follow-up discussion on the build system please into this thread: https://groups.google.com/d/msg/sage-devel/WmykUtM4Gi0/qm6tH5i8b8UJ -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On Sun, Jan 12, 2014 at 9:15 PM, Volker Braun wrote: > At the risk of veering even further off-topic, I would like to give up "tree > relocation" as it is currently defined. Its cumbersome (need to check that > we haven't been moved all the time) and insecure. > > For relocatable binaries, we build with / rewrite rpaths to be relative and > make all libtool .la files have relative paths. This may require further > dependencies, like tools to rewrite rpaths. Also, once you unpack the binary > and start compiling further stuff in its directory it may or may not be > relocatable any more. But really the goal is to distribute binaries, not > allow you to move your sage directory around all the time. All modern > linuxes and intel OSX allow relative rpaths and its modification with the > help of special tools. I don't think this is off topic and I think you make a very good point. Relocation (as I defined it) is not the goal. The goal is to build user-installable binaries. If what you suggest above works with a given build system, then that satisfies the design constraints. Has anybody listed the functionality constraints, i.e., the problem we are discussing? Here is a very rough first stab. - user-installable binaries - tested (as Volker defined above) - supports our platforms, e.g., OS X, Solaris, Linux, Cygwin, ?? - parallel build from source must be fast - upgrades of binaries without having to compile anything would be nice (we do not have that now) - ability to uninstall packages (which we do not have now) I think building in parallel is the part of the current build system that was by far the hardest, and for which most effort has probably been spent. The time it takes to do a full build from source on a fast multi-core machine is an absolutely critical benchmark for whatever is proposed. -- William > > > > On Monday, January 13, 2014 12:00:55 AM UTC-5, William wrote: >> >> Of course, relocation is really a way to solve the problem "build a >> sage binary once and make it available to other people to install in >> their home directory". I don't know of any other way to solve that >> problem. I also don't know if *any* of the non-Sage build systems in >> this thread support relocation of binaries. >> > -- > 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 sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
At the risk of veering even further off-topic, I would like to give up "tree relocation" as it is currently defined. Its cumbersome (need to check that we haven't been moved all the time) and insecure. For relocatable binaries, we build with / rewrite rpaths to be relative and make all libtool .la files have relative paths. This may require further dependencies, like tools to rewrite rpaths. Also, once you unpack the binary and start compiling further stuff in its directory it may or may not be relocatable any more. But really the goal is to distribute binaries, not allow you to move your sage directory around all the time. All modern linuxes and intel OSX allow relative rpaths and its modification with the help of special tools. On Monday, January 13, 2014 12:00:55 AM UTC-5, William wrote: > > Of course, relocation is really a way to solve the problem "build a > sage binary once and make it available to other people to install in > their home directory". I don't know of any other way to solve that > problem. I also don't know if *any* of the non-Sage build systems in > this thread support relocation of binaries. > > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On Sun, Jan 12, 2014 at 8:09 PM, Francois Bissey wrote: > Relocation. Technically possible. In practise hard to achieve as it involves > rewriting > runpath inside binaries, this is highly OS dependent. The prefix solves > Volker's > LD_LIBRARY_PATH problem at the cost of relocation. Other gain dear to Volker: > we can use any blas/lapack we want. For the record, I view relocation as an important requirement of any build system we adopt. To me, "relocation" means that you can build Sage in /this/directory, then type "mv /this/directory /that/path; /that/path/sage" and have it work, though it may take a while. Obviously, it would be desirable if this isn't a major security risk (I know Volker has pointed out some important issues with this.) Of course, relocation is really a way to solve the problem "build a sage binary once and make it available to other people to install in their home directory". I don't know of any other way to solve that problem. I also don't know if *any* of the non-Sage build systems in this thread support relocation of binaries. -- William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On Sunday, January 12, 2014 11:09:23 PM UTC-5, François wrote: > > OS X support. Almost 3 years ago with Georg we tackled it and I had sage > build > in a 32bit prefix on 10.5.8 up to sage 5.9 I think. There are a number of > prefix that > degraded that state. That is what I meant by "automated testing". Verifying that each version runs on all supported platforms (ideally containing the Sage supported platforms). And if it a proposed change breaks one of them then its not merged. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
RE: [sage-devel] Re: Python as build-time dependency
I should have invited myself to the conversation earlier I guess. I usually avoid those discussion because I could be seen as coming with a political agenda. Technically I don't really care what sage does so long as it doesn't get in the way of what I am doing with regards to gentoo/prefix. Whether you go for easybuild (http://hpcugent.github.io/easybuild/) conda or another equivalent is fine by me. portage? I would be flattered and there are a number of things to deal with - which we can discuss further later. OS X support. Almost 3 years ago with Georg we tackled it and I had sage build in a 32bit prefix on 10.5.8 up to sage 5.9 I think. There are a number of prefix that degraded that state. At the time of the initial work with Georg we had successfully build ppc, x86 and x64 targets. Like I said there are trouble in prefix on OS X that make things difficult. It may be that the new (alternative) RAP prefix which build its own glibc could smooth all the problem. portage is fine in my opinion for sage. The number of package that I have installed and the number of customization of options (some of which are for sage-on-gentoo) mean that I sometimes have a very complicated dependency tree for portage to sort which make it look slow. pkgcore may be better. Relocation. Technically possible. In practise hard to achieve as it involves rewriting runpath inside binaries, this is highly OS dependent. The prefix solves Volker's LD_LIBRARY_PATH problem at the cost of relocation. Other gain dear to Volker: we can use any blas/lapack we want. Automated testing. I am not sure what Volker meant by that. In Gentoo you can set the feature "test" which will run the testsuite of the package before it is merged - provided that the ebuild allows it, the tests exist and it make sense. Currently we run the sage testsuite after sage is merged. Testing sage before merge would require a lot of work from our current point. François I guess I can claim "lead sage-on-gentoo developer" as a title. From: sage-devel@googlegroups.com [sage-devel@googlegroups.com] on behalf of Michael Orlitzky [mich...@orlitzky.com] Sent: Monday, 13 January 2014 10:39 To: sage-devel@googlegroups.com Subject: Re: [sage-devel] Re: Python as build-time dependency On 01/12/2014 03:51 PM, R. Andrew Ohana wrote: > I'm a fan of gentoo's package manager specification (PMS) [1], however > the only package manager that is fully compliant is portage, which I > don't think is appropriate for sage. In particular: Keep in mind that the alternative is a bunch of hand-rolled python and bash scripts that punt on all of the hard problems that portage solves. > 1. It requires a noticeably bigger bootstrapping of the world. Lmonade > reduces this to only ~20 more packages than we already have (if I > recall), but imo this is still too many. Sage needs most of these too, they just aren't listed as dependencies anywhere. Things like binutils and glibc are assumed to exist. The fact that we don't build them explicitly in sage is a source of bugs. > 2. Portage itself has many dependencies, often with very explicit > version requirements. This makes non-Linux platforms a pain, since you > need things like gnu coreutils and findutils. Those two examples build and run fine on non-Linux platforms. Portage itself has very few dependencies, you can see them in its ebuild. There is the "implicit system" dependency that you get from prefix, but only one or two of those have version bounds, and it's all stuff that sage uses. > 3. It does not support tree relocation. What do you mean by this? > 4. (Lesser) The Portage source is atrocious, and it performs terribly. > > Imo, the most promising implementation of the PMS is paludis, however it > is not fully compliant (in particular prefix support is incomplete, and > binaries are assumed to be in the ELF format). > > [1] http://wiki.gentoo.org/wiki/Project:PMS If for the sake of argument we rule out portage, I would concentrate on pkgcore instead. It's missing EAPI5 support at the moment, but there's some discussion in Gentoo about whether to switch the focus from portage to pkgcore in the long term. Otherwise it's fast, clean, written in python, and the spiritual successor to portage. But portage is fine. It's running tens of thousands of Gentoo machines, and somebody else writes it for you, which is where we stand to benefit the most. Dependency resolution is the slow part, and users would rarely need to emerge anything. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegr
Re: [sage-devel] Re: Python as build-time dependency
On 01/12/2014 03:51 PM, R. Andrew Ohana wrote: > I'm a fan of gentoo's package manager specification (PMS) [1], however > the only package manager that is fully compliant is portage, which I > don't think is appropriate for sage. In particular: Keep in mind that the alternative is a bunch of hand-rolled python and bash scripts that punt on all of the hard problems that portage solves. > 1. It requires a noticeably bigger bootstrapping of the world. Lmonade > reduces this to only ~20 more packages than we already have (if I > recall), but imo this is still too many. Sage needs most of these too, they just aren't listed as dependencies anywhere. Things like binutils and glibc are assumed to exist. The fact that we don't build them explicitly in sage is a source of bugs. > 2. Portage itself has many dependencies, often with very explicit > version requirements. This makes non-Linux platforms a pain, since you > need things like gnu coreutils and findutils. Those two examples build and run fine on non-Linux platforms. Portage itself has very few dependencies, you can see them in its ebuild. There is the "implicit system" dependency that you get from prefix, but only one or two of those have version bounds, and it's all stuff that sage uses. > 3. It does not support tree relocation. What do you mean by this? > 4. (Lesser) The Portage source is atrocious, and it performs terribly. > > Imo, the most promising implementation of the PMS is paludis, however it > is not fully compliant (in particular prefix support is incomplete, and > binaries are assumed to be in the ELF format). > > [1] http://wiki.gentoo.org/wiki/Project:PMS If for the sake of argument we rule out portage, I would concentrate on pkgcore instead. It's missing EAPI5 support at the moment, but there's some discussion in Gentoo about whether to switch the focus from portage to pkgcore in the long term. Otherwise it's fast, clean, written in python, and the spiritual successor to portage. But portage is fine. It's running tens of thousands of Gentoo machines, and somebody else writes it for you, which is where we stand to benefit the most. Dependency resolution is the slow part, and users would rarely need to emerge anything. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
I'm a fan of gentoo's package manager specification (PMS) [1], however the only package manager that is fully compliant is portage, which I don't think is appropriate for sage. In particular: 1. It requires a noticeably bigger bootstrapping of the world. Lmonade reduces this to only ~20 more packages than we already have (if I recall), but imo this is still too many. 2. Portage itself has many dependencies, often with very explicit version requirements. This makes non-Linux platforms a pain, since you need things like gnu coreutils and findutils. 3. It does not support tree relocation. 4. (Lesser) The Portage source is atrocious, and it performs terribly. Imo, the most promising implementation of the PMS is paludis, however it is not fully compliant (in particular prefix support is incomplete, and binaries are assumed to be in the ELF format). [1] http://wiki.gentoo.org/wiki/Project:PMS -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On Sun, Jan 12, 2014 at 01:09:42PM -0500, Michael Orlitzky wrote: > Prefix is designed to run as an ordinary user on non-gentoo systems. If > you're on gentoo, you don't need it (unless you don't have root). Plenty > of us have been able to get it working, so if we made a concerted > effort, I'm sure we could stick a nice UI on it. Besides, it's currently > working better than the nonexistent rewrite being discussed. the nonexistant rewrite exists as a demo [1]. it is based on autotools (not python). it is mostly boilt down to calling the spkg-install programs in the right order, while being semantically similar to the current toplevel makefiles and scripts. it also supports package content lists (to possibly remove/exchange packages) and is able to optionally completely disable packages (fallback to system packages). i'm sure a python script could as well be used to call the spkg-install programs in the right order and do fancy stuff. but similar to the autotools build system, it will not be able to guess package contents without some tiny spkg-install modifications like [2]. imo, sage should stay distribution independent, distributions other than sage should only require to package sagelib in the end. and whatever happens next, sage (the library) should be freed from hardcoded paths and from package management code, so not everybody has to work that out again and again, YMMV of course. have fun felix [1] http://tool.em.cs.uni-frankfurt.de/~felix/sage [2] http://trac.sagemath.org/ticket/15136 -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On Sunday, January 12, 2014 8:09:42 AM UTC-10, Michael Orlitzky wrote: > > > lmnd currently does not work on OSX and other exotic platforms. > Prefix works on OSX, so whatever's wrong is fixable. I'm sure your help would be appreciated at lmona.de. We'll be happy to consider it when it is ready. Prefix is designed to run as an ordinary user on non-gentoo systems. There is no automatted testing, so it does not work. This is not about a nice UI, just being able to build without user interaction. Lmnd aims to fill this gap, among others. But I think we agree that it is not ready yet. The releases shouldn't have anything to do with the git tree. Well, they do. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On 01/12/2014 12:03 PM, Volker Braun wrote: > On Sunday, January 12, 2014 6:41:21 AM UTC-10, Michael Orlitzky wrote: > > At this point I must conjure the semi-regular reminder that > "cross-platform homebrew" already exists in the form of Gentoo Prefix. > > > We are aware of gentoo prefix and lmnd. > > lmnd currently does not work on OSX and other exotic platforms. > Prefix works on OSX, so whatever's wrong is fixable. > I've tried lmnd and prefix occasionally on Fedora and have almost always > run into problems. It does not "just work", even on a current Linux > system. Including wonky errors where gentoo prefix wants to start manage > uids on my system etc. I don't think there is any real regression > testing for gentoo prefix on common platforms outside of lmnd. It is > mostly tested as part of gentoo, but we would only want a small part of > the gentoo system. Prefix is designed to run as an ordinary user on non-gentoo systems. If you're on gentoo, you don't need it (unless you don't have root). Plenty of us have been able to get it working, so if we made a concerted effort, I'm sure we could stick a nice UI on it. Besides, it's currently working better than the nonexistent rewrite being discussed. > Also, we want a system to rebuild sage according to our git tree status. > In particular, no time stamps. But take version and dependency > information out of our git tree. And possibly store old builds (tarball > or other packaging system). The releases shouldn't have anything to do with the git tree. Normal users would download prefix bundled with sage-on-gentoo and `emerge sage` to install. Version and dependency information go in the ebuild: https://github.com/cschwan/sage-on-gentoo/blob/master/sci-mathematics/sage/sage-.ebuild (i.e. as the responsibility of the package manager, as god intended.) When sage is run, it expects that stuff to be there -- no need to reimplement the package manager. If you want to develop, you'd clone the git repo inside prefix and go about your business. The deviations from upstream (via patches) are incorporated in sage-on-gentoo. "Sage" thus becomes "The Sage Library" and we can finally do away with the 500 megabytes of copy/paste that we've been hauling around for years. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On Sunday, January 12, 2014 6:41:21 AM UTC-10, Michael Orlitzky wrote: > > At this point I must conjure the semi-regular reminder that > "cross-platform homebrew" already exists in the form of Gentoo Prefix. > We are aware of gentoo prefix and lmnd. lmnd currently does not work on OSX and other exotic platforms. I've tried lmnd and prefix occasionally on Fedora and have almost always run into problems. It does not "just work", even on a current Linux system. Including wonky errors where gentoo prefix wants to start manage uids on my system etc. I don't think there is any real regression testing for gentoo prefix on common platforms outside of lmnd. It is mostly tested as part of gentoo, but we would only want a small part of the gentoo system. Also, we want a system to rebuild sage according to our git tree status. In particular, no time stamps. But take version and dependency information out of our git tree. And possibly store old builds (tarball or other packaging system). -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On 01/12/2014 04:16 AM, Javier López Peña wrote: > On Sunday, January 12, 2014 2:20:03 AM UTC, William wrote: > > Thanks for reminding people of conda. One issue is that Sage's build > system is far more than just for installing Python package -- it's > much, much more (e.g., Gap, Singular, etc.). > > > conda started off as a python package manager, but is not limited to > them anymore; it will build and install anything for which it has a > recipe: LLVM, python itself, C libraries, R packages, it doesn't matter, > all is put at the same level (Travis described it as a 'cross-platform > homebrew'). > At this point I must conjure the semi-regular reminder that "cross-platform homebrew" already exists in the form of Gentoo Prefix. It's got years of work behind it, it's heavily tested, and other people do the work for you -- all we'd have to do is put the desired versions of stuff in a text file. Even that work is done in the form of sage-on-gentoo. So we'd just need to package it up along with some build instructions in a form that users can follow. But lmonade is pretty good at that. We might need to make some adjustments, but the proof-of-concept is there and a lot of the hard work is already done. If you survived the git migration it would seem like a piece of cake. We'd get to remove the package management features from sage, and it would eliminate Volker's best friend the LD_LIBRARY_PATH hack. We would still be installing the universe from scratch, but at least we'd be doing it right. It's also a big step towards getting distros to package sage. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On Sunday, January 12, 2014 2:20:03 AM UTC, William wrote: > > Thanks for reminding people of conda. One issue is that Sage's build > system is far more than just for installing Python package -- it's > much, much more (e.g., Gap, Singular, etc.). > conda started off as a python package manager, but is not limited to them anymore; it will build and install anything for which it has a recipe: LLVM, python itself, C libraries, R packages, it doesn't matter, all is put at the same level (Travis described it as a 'cross-platform homebrew'). The build framework [1] doesn't actually look much different from what we do with spkg's. Cheers, J [1] http://docs.continuum.io/conda/build.html -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On Sat, Jan 11, 2014 at 3:02 PM, Javier López Peña wrote: > On Saturday, January 11, 2014 4:37:56 PM UTC, William wrote: >> >> Andrew's main argument is that there is strong interesting in writing >> a nontrivial new build system that solves our unique set of problems >> with Sage (since no existing build system does). > > > I am not qualified to discuss the advantages of different build systems, > but if the build system of Sage is to be redesigned, it might be worth > taking a look into conda [1], the build system designed by Travis Oliphant > (the guy largely responsible for NumPy) for the Anaconda python distribution > (and later open-sourced). Travis makes an argument for conda here [2]. > > From what I have seen, it addresses some problems similar to the ones > faced by sage, although the installation philosophy might be somewhat > different. > > Not saying conda is the right tool for Sage, but looking into it could save > from some > wheel-reinventing. Thanks for reminding people of conda. One issue is that Sage's build system is far more than just for installing Python package -- it's much, much more (e.g., Gap, Singular, etc.). > > Cheers, > J > > [1] https://github.com/pydata/conda > [2] > http://technicaldiscovery.blogspot.com.es/2013/12/why-i-promote-conda.html > > -- > 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 sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On Saturday, January 11, 2014 4:37:56 PM UTC, William wrote: > > Andrew's main argument is that there is strong interesting in writing > a nontrivial new build system that solves our unique set of problems > with Sage (since no existing build system does). > I am not qualified to discuss the advantages of different build systems, but if the build system of Sage is to be redesigned, it might be worth taking a look into conda [1], the build system designed by Travis Oliphant (the guy largely responsible for NumPy) for the Anaconda python distribution (and later open-sourced). Travis makes an argument for conda here [2]. >From what I have seen, it addresses some problems similar to the ones faced by sage, although the installation philosophy might be somewhat different. Not saying conda is the right tool for Sage, but looking into it could save from some wheel-reinventing. Cheers, J [1] https://github.com/pydata/conda [2] http://technicaldiscovery.blogspot.com.es/2013/12/why-i-promote-conda.html -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
I would also add that even if Python and bash (or is it POSIX shell) were equally expressive, using the same language for the build system as the main library is a significant improvement from a readability/potential contributor angle. In particular shell is a particularly dangerous language to only half-know and write something that works just for you (how many people instinctively think to write "x$var" = "xYes" ...) On Sat, Jan 11, 2014 at 8:37 AM, William Stein wrote: > On Fri, Jan 10, 2014 at 9:55 PM, Volker Braun wrote: >> In practice Python is one of the non-specialist-maths parts that has a >> decent build system, so building it isn't hard either way. > > I agree.I talked with Andrew about this and he convinced me that > making Python 2.6 a build dependency is a good idea. > For the Sage-supported OS's for which Python 2.6+ isn't trivial to > install (which?), we can provide instructions so that people can build > Python 2.6 (which is pretty easy). > > Andrew's main argument is that there is strong interesting in writing > a nontrivial new build system that solves our unique set of problems > with Sage (since no existing build system does). Doing this would be > far too painful using shell, but very reasonable using python 2.6. > Also, most existing *supported* OS's (e.g., Ubuntu 12.04, but not > 8.04) include python 2.6 by default. > > I think there's more than sufficient programming talent (between > Andrew, Volker, etc.) to write a new build system; the main problem is > knowing exactly what problems it should solve, and what the > constraints should be. With almost 9 years of experience now, we have > the data to come up with the right thing.Despite its shortcomings, > already the current build system is the easiest way for certain people > -- who don't use Sage -- to get certain software (as I'm often told). > It's natural in light of the re-organization that happened during the > git transition for us to move on to re-doing the build system. > Allowing it to be written in Python 2.6+ would make it potentially > much more useful. > > -- William > >> >> On Friday, January 10, 2014 1:04:09 AM UTC-10, mmarco wrote: >>> >>> So we would use python to run the buildiing scripts for the sage >>> components... including python itself? >> >> -- >> 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 sage-devel+unsubscr...@googlegroups.com. >> To post to this group, send email to sage-devel@googlegroups.com. >> Visit this group at http://groups.google.com/group/sage-devel. >> For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > > -- > 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 sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python as build-time dependency
On Fri, Jan 10, 2014 at 9:55 PM, Volker Braun wrote: > In practice Python is one of the non-specialist-maths parts that has a > decent build system, so building it isn't hard either way. I agree.I talked with Andrew about this and he convinced me that making Python 2.6 a build dependency is a good idea. For the Sage-supported OS's for which Python 2.6+ isn't trivial to install (which?), we can provide instructions so that people can build Python 2.6 (which is pretty easy). Andrew's main argument is that there is strong interesting in writing a nontrivial new build system that solves our unique set of problems with Sage (since no existing build system does). Doing this would be far too painful using shell, but very reasonable using python 2.6. Also, most existing *supported* OS's (e.g., Ubuntu 12.04, but not 8.04) include python 2.6 by default. I think there's more than sufficient programming talent (between Andrew, Volker, etc.) to write a new build system; the main problem is knowing exactly what problems it should solve, and what the constraints should be. With almost 9 years of experience now, we have the data to come up with the right thing.Despite its shortcomings, already the current build system is the easiest way for certain people -- who don't use Sage -- to get certain software (as I'm often told). It's natural in light of the re-organization that happened during the git transition for us to move on to re-doing the build system. Allowing it to be written in Python 2.6+ would make it potentially much more useful. -- William > > On Friday, January 10, 2014 1:04:09 AM UTC-10, mmarco wrote: >> >> So we would use python to run the buildiing scripts for the sage >> components... including python itself? > > -- > 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 sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python as build-time dependency
In practice Python is one of the non-specialist-maths parts that has a decent build system, so building it isn't hard either way. On Friday, January 10, 2014 1:04:09 AM UTC-10, mmarco wrote: > > So we would use python to run the buildiing scripts for the sage > components... including python itself? > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python as build-time dependency
So we would use python to run the buildiing scripts for the sage components... including python itself? Maybe it is better in the long term, but it sounds weird. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python as build-time dependency
On 01/08/2014 03:39 PM, Jean-Pierre Flori wrote: What scripting language use Gentoo in ebuilds? Essentially, ebuilds are in bash, although portage is in python. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python as build-time dependency
+1 On Tuesday, January 7, 2014 12:10:38 AM UTC-8, Volker Braun wrote: > > We were considering the addition of Python as a build-time dependency to > be able to use Python even for scripts that are used at bootstrap time here > at SD56. And everybody was in favor. We should probably support Python 2.5 > - 2.7 and 3.3+, which would cover the default system python on pretty much > any system where Sage builds out of the box. And those on systems where you > have to jump though hoops to get the other Sage dependencies, installing a > halfway-recent Python is the least of your problems. > > > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.