[Distutils] GCC versions and binary egg names

Chris Withers 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 
actual example?

> 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
> not.

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
> issues.

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,
> etc...

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
            - http://www.simplistix.co.uk

More information about the Distutils-SIG mailing list