[Distutils] GCC versions and binary egg names

David Cournapeau cournape at gmail.com
Tue Jul 27 12:14:55 CEST 2010


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.

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

>
>> I would strongly look into system packages-based solutions unless you
>> really cannot use them (non root install).
>
> I pertty strongly disagree. In a heterogenous operating system environment,
> where that environment includes MacOS and Windows, trying to maintain
> separate os packages for each of the os packaging systems is a nightmare.

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.

EPD can use eggs because they pretty much control the whole stack from
python, hence significantly reducing the issues of dependencies
issues.

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

cheers,

David


More information about the Distutils-SIG mailing list