[Distutils] GCC versions and binary egg names
chris at simplistix.co.uk
Sat Jul 31 18:34:35 CEST 2010
David Cournapeau wrote:
> On Tue, Jul 27, 2010 at 5:36 PM, Chris Withers <chris at simplistix.co.uk> wrote:
>> Indeed, but the other option requires a more complicated service to query.
>> Being able to "serve" packages from a simple folder or from simple folder
>> served via svn or Apache is a huge win.
> I don't see how one preclude the other.
How would you serve your proposed "rich" environment from Apache?
>>> The combination alone makes it complicated very fast. Trying
>>> to come up with such a scheme in python is foolish IMHO: the problem
>>> is complicated, and nobody has been able to solve it in a general
>>> manner anyway.
>> I think that's overly pessemistic. What problems do you see with the
>> multiple-find-links suggestion I made above?
> It quickly becomes intractable once you have complex requirements.
Again, I think you're being overly pessimistic. Please can you give an
> I don't see how egg changes anything there compared to rpm/deb to that
> issue. At least, rpm/deb and the infrastructure around have been
> designed to somewhat deal with those issues, whereas egg clearly was
rpm/deb focus only on their own operating system. They don't help with
Windows or MacOS. Eggs work the same on all platforms, from the clients
perspective, it's just a case of making the right eggs available that
appears to be problematic.
> EPD can use eggs because they pretty much control the whole stack from
> python, hence significantly reducing the issues of dependencies
I don't follow. EPD uses a whole host of dependencies that are non-python...
>> Working with sdists as much as possible with binary eggs thrown in where
>> possible seems like the best way forward for me. What are the problems you
>> see with that solution?
> The numerous issues of dealing with ABI issues on Linux are well
> known. First there is UCS2 vs UCS4 for python extensions, then there
> is gcc versions and stdlib versions for C++, then you will also have
> issues with gfortran vs g77 which do not have compatible ABI either,
Indeed, but as I said before, this is a constrained environment.
Ubuntu 8.04 or 10.04, each with a controllable list of installed
packages. With Windows and MacOSX, python packagers seem to go the route
of statically linking anyway...
Simplistix - Content Management, Batch Processing & Python Consulting
More information about the Distutils-SIG