Re: [sage-devel] removing pickles for old k-Schur implementation
Hi! I agree with Travis that we should just remove the jar, given that the old k-Schurs were deprecated for over a year! Best, Anne On Sun, Jan 12, 2014 at 10:44 PM, Travis Scrimshaw wrote: > Hey everyone, >This is not easy as I have been trying to fix this for a few hours (but > there is always the possibility that I'm doing something wrong). Here's > what I believe to be going on. > > 1 - The unreduce from UniqueRepresentation is overriding the __setstate__, > which is then calling the __init__() of kSchurFunctions_t, *not* the > __setstate__() (which is never called). > 2 - The register_unpickle_override() is ignored; probably a side effect of > 1. > 3 - I must have a module kschur; probably a side effect of 1. > > I believe 1 is a bug, and if 2 and 3 are not related to 1, IMO they are > also bugs. However, considering that we've had this deprecated, I believe > we should just remove the corresponding pickles from the jar. > > Best, > Travis > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sage-devel" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sage-devel/KjnxIXO-xnE/unsubscribe. > To unsubscribe from this group and all its topics, 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] removing pickles for old k-Schur implementation
Hey everyone, This is not easy as I have been trying to fix this for a few hours (but there is always the possibility that I'm doing something wrong). Here's what I believe to be going on. 1 - The unreduce from UniqueRepresentation is overriding the __setstate__, which is then calling the __init__() of kSchurFunctions_t, *not* the __setstate__() (which is never called). 2 - The register_unpickle_override() is ignored; probably a side effect of 1. 3 - I must have a module kschur; probably a side effect of 1. I believe 1 is a bug, and if 2 and 3 are not related to 1, IMO they are also bugs. However, considering that we've had this deprecated, I believe we should just remove the corresponding pickles from the jar. Best, Travis -- 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: Sage build system
Another bullet point, related to being able to package and store the installed files: - downgrades should work and be fast, so you can easily go back to an old ticket -- 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] Sage 6.x documentation
On Mon, Jan 13, 2014 at 6:26 AM, Minh Nguyen wrote: > I think the transition to git has messed up my > build scripts. ... > Anyway, someone updated the documentation (thanks!). Sorry for the > miscommunication that resulted in the delay. no problem, everyone needs a break sometimes ;-) I was the one who fixed this build-doc script and then updated the documentation. So far I didn't hear of any complaints that something has been broken. Harald -- 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.
[sage-devel] Sage build system
[top-posted reply to start an appropriately-named thread] On Monday, January 13, 2014 12:26:30 AM UTC-5, William wrote: > 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. One point of conflict is that we currently do not distinguish between configure, build, and install. Hence: * We cannot track installed files without serializing everything * We cannot simply set relative rpaths since configure will run binaries in the build directory (and not $SAGE_ROOT/local/bin) We also talked a bit about that at SD56 and the favored solution was to split build scripts into bash functions to separate configure/build/install, this is very similar to gentoo. We probably want to allow python build scripts, too, so similar functions in a Python script should be allowed as well. -- 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] Sage build system
[changed subject to end up top-posted] On Monday, January 13, 2014 12:26:30 AM UTC-5, William wrote: > > 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. One point of conflict is that we currently do not distinguish between configure, build, and install. Hence: * We cannot track installed files without serializing everything * We cannot simply set relative rpaths since configure will run binaries in the build directory (and not $SAGE_ROOT/local/bin) We also talked a bit about that at SD56 and the favored solution was to split build scripts into bash functions to separate configure/build/install, this is very similar to gentoo. We probably want to allow python build scripts, too, so similar functions in a Python script should be allowed as well. -- 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] Sage 6.x documentation
Hi, On Sun, Dec 22, 2013 at 7:40 PM, Marc Mezzarobba wrote: > As noticed by Paul Zimmermann, http://www.sagemath.org/doc/ still points > to the documentation of Sage 5.13. For regular manuals, it shouldn't > make any difference until sage-6.1 is released, however the developer > guide is out of date. This is a miscommunication on my part. When Sage 6.0 was released, I didn't see any binaries for boxen.math under /home/release/sage-6.0 so I waited a while. After a few days, I still couldn't find a binaries so I tried building sage-6.0 on boxen.math, but couldn't get it to build successfully. I think the transition to git has messed up my build scripts. I decided to wait for the binaries and in the meantime went on a vacation to recover from an intensive year of work. Anyway, someone updated the documentation (thanks!). Sorry for the miscommunication that resulted in the delay. -- Regards, Minh Van Nguyen http://bit.ly/mvngu -- 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@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out. This email may be confiden
Re: [sage-devel] removing pickles for old k-Schur implementation
Hi Anne, Have you tried writing a custom __setstate__ method for the kSchur functions? This should be all that is necessary. I ran into a similar problem when I moved Partition into the category framework and all that was required was def __setstate__(self, state): if isinstance(state, dict): # for old pickles from Partition_class self._set_parent(_Partitions) self.__dict__ = state else: self._set_parent(state[0]) self.__dict__ = state[1] I haven't looked at all at your new code, but I did look at the current implementation of kSchur functions and its __getstate__ function is just returning a dictionary -- just like Partition used to -- so I suspect that essentially the changing the parent in the code above is all that you need to do. Andrew On Saturday, 11 January 2014 22:50:06 UTC+1, anne1.s...@gmail.com wrote: > > > http://www.sagemath.org/doc/developer/coding_basics.html#the-pickle-jarsays: >> >> Warning Sage’s pickle jar helps to ensure backward compatibility in sage. >> Pickles should only be removed from the pickle jar after the corresponding >> objects have been properly deprecated. Any proposal to remove pickles from >> the pickle jar should first be discussed on sage-devel. >> >> I agree it would be best to use the override mechanism, though it might >> be an unjustifiable amount of work depending on how much the new kSchur >> implementation changed. If it comes down to keeping a bunch of dead code >> vs. removing something from the pickle jar, we should just do the latter. >> >> "Tradition is a guide and not a jailer" >> > > If someone can help us to figure out how to override the deprecated > pickles, then I would be happy to do it. Otherwise, let's remove them (I > think the people mostly using the code are anyway Mike and me, and we do > not need the old pickles ). > > Best, > > Anne > -- 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 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.
