On Jul 20, 1:22 pm, "Ondrej Certik" <[EMAIL PROTECTED]> wrote:
<SNIP>
Hi Ondrej,
> > Nope, it does not work for example on OSX. With a python 2.5.2 on
>
> I don't understand the OSX problems about universal/non universal
> python (ucs2 vs ucs4 surely can be fixed).
>
> > Linux x86 and x86 it should mostly work, but on Linux Itanium it does
> > not work since in the official 2.5.2 readline is busted. On Solaris
>
> That really sucks. I hope upstream fixes that.
I am not even sure the Python people know. IIRC William told me that
at lease SLES on Itanium just disabled building the readline extension
for Python.
> > 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 :)
> > 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.
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 :)
> >> As chatted on IRC, the LD_LIBRARY_PATH problem *might* get fixed using:
>
> >>http://packages.debian.org/sid/chrpath
>
> > Yes, this certainly offers possibilities.
>
> Fortunately.
Yes, I think we can fix that via some script to make you happy :)
> Ondrej
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
