> We officially reported the bug to them via their tracker. > Then one Sage developer worked for a long time and > heroically found a fix and reported it too. I think it maybe > just takes a long time to filter through the system back > to the *deployed* RHEL and SLES linux boxes all over > the place. I.e., using the system-wide Python by > default just isn't an option. And of course a lot of users > want to install Sage without having to be root, and they > don't know anything about Python or installing it themselves.
I see. >>> > and OSX there is also the multilib issue, i.e. 32 vs. 64 bit are >>> > supported on the same machine. So I disagree that it mostly works and >>> > I consider it a bad, bad idea to even give the user some simple option >>> > to make Sage build with the system python. It is trivial to do if you >>> > know your way around the Sage build system, but that actually means >>> > that one can likely fix issues oneself like in your case. Everybody >>> > else just has to play by the rules. >>> >>> Well, if the situation is that the system wide python is so different >>> on different machines that it makes Sage fail, then it sucks. Imho. >> >> It won't necessarily fail, but there are many possibilities for >> potentially very subtle bugs. And since I spend an (unresonable) >> amount of time chasing down pretty much every issue reported I would >> prefer that the number of variables does not increase. In addition it >> is not my fault that Apple decided that a universal Python is the way >> to go. Once we switch to a pure 64 bit Python on OSX Apple's python >> won't work at all any more anyway. >> >> And this problem on OSX is not some hypothetical issue: I spend two >> hours a couple weeks ago debugging a python import module failure on >> OSX where universal libraries played a role and the linker happily >> linked together an x86 extension and a ppc library. The import of the >> module failed and it was far from clear why. And if it takes me two >> hours to figure out you can guess what I would assume what would >> happen to most people. And in that case the situation was clear cut >> and I had shell access to the box in question. Now imagine debugging >> that problem by email :) > > Also let me add that the goal of Sage is to provide a viable alternative > to the Ma's and that all of those programs are self-contained. Our design > decisions are very much motivated by the Sage mission statement. We > have to be really focused on that goal, and consequently *not* worry about > certain other very worthy goals like nicely integrating as a library. That's > not to say that it isn't *wonderful* that some people like Tim Abbot are > doing an amazing job on the goal of integrating as a library. Speaking > of which, I think debian-sage is the perfect solution for you Ondrej. > Of course you know all about it since you're very involved in that effort. > (I get the sense it will be ready soon too.) Unfortunately not lately, but I at least created the list and wiki pages. So all credit goes to Tim. He has done a fenomenal job. Yes, That should fix the problem. Nevertheless I still want to find ways to easily test newest Sage and newest SymPy in some canonical way without messing up with paths and shooting myself in the foot, to use mabshoff's words. > >>> > And I won't post the obvious one line diff to make Sage with system >>> > python at build time work. If you need to ask you shouldn't play with >>> > something that could cause endless trouble :p >>> >>> I understand your point as the release manager, but from the users >>> point of view, if every program distributed all the libraries (python, >>> fortran, libxml, and all the other stuff that ships with sage), and it >>> would be incompatible with the other installations, as currently Sage >>> is incompatible with systemwide python as you stressed several times, >>> then it's bad, because I cannot mix Sage with other components on my >>> system. So it's Sage and the rest of the world. >> >> Well, Sage works because it is self contained and it is only possible >> to work because it is self contained. We can fix bugs rapidly because >> we nearly control 100% of the components and its dependencies of Sage. >> No one ever promised that Sage would play well with your system and >> installing Python packages into a Sage install is trivial. You can >> trivially use your system's Python, but I have no intentions of making >> it easy on you because other people will see the email and will shoot >> themselves in the foot. Even once Sage is in Debian proper I will not >> consider anything a bug unless it can be reproduced with a vanilla >> Sage build from sources. There is only one official Sage release and >> it will not be the one in any distribution. I seriously doubt that any >> distribution can keep up with the official Sage. > > That said, it will be very good for there to be a Sage in Debian, and > I'm really looking forward to the day that happens. I know because > before for many many users I was personally a Linux user users -> years? How many years were you using linux and why did you switch to Mac OS X? I am thinking of buying a macbook, but installing Debian on it. :) > for which the world of software was equal to the world of > packages available in rpm or deb's. I can understand that perspective, > and want to make using Sage easy for such people. I understand the other perspective too, and actually, I may endup teaching some undergrad classes in a year or two, so I will use Sage package, not Sage debian package, simply because the people will be using windows, not Debian. Or they will use ubuntu, but still it's easy to just download and untar. Even though unfortunately, on my laptop it takes many minutes, maybe up to 15 min together (download+untarring+first sage run). > >> One big issue I see: What are you going to do when the Sage project >> updates to Python 2.6 and then to 3.0 and Debian does not keep pace or >> the other way around when say Debian moved to Python 3 before we do. >> Then you just FUBARed your current Sage install and people will blame >> Sage and not their own stupidity. The same applies to the issue with >> symbols in libz that you initially reported. It is trivial to >> understand why it happens but again I suspect that many people will >> blame Sage and not even report it to the mailing list. And those are >> the people who might then go back to some other CAS and have the >> impression that Sage sucks. So in the end I see it like this: A minor >> inconvenience you can fix by thinking about it for a second vs. a >> potentially huge fuckup for loads of n00bs - I don't have to think >> about the choices here :) > > I strongly agree with this. And it is people exactly not getting > this point that is I think a big problem that has really held back > open source math software from providing a genuine alternative > to the Ma's for power users like me or your typical calculus > student. I strongly agree with this too. Some people say I see things too much in black and white (was it you?:) and they are right. I think that if you download a program and untar it, it needs to just work without setting anything. Maybe doing one "make", if there is no binary. If it fails, it's a showstopper and I think it's a perfectly valid reason to go to some other CAS that just works. Nevertheless I also think that a good program first needs to satisfy the above, but if it does and there are resources then it should be also possible to tweak it in a way to do things that I want. If you know what I mean. So I will continue crafting that little script that will make me happy. Ondrej --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
