[Distutils] [RFC] eggbuild

[Alan Franzoni]

On 11/4/10 11:09 PM, Manlio Perillo wrote:

Sorry for being late, I had a busy Friday.

>> If you want to, let's say, distribute something built with PyQt on
>> Linux, you'll need PyQt, the QT Runtime, then? most probably X libs,
>> libc and something else. Do you *really* want to distribute everything?


> A simple solution is to specify, in the setup.cfg file, a list of "know"
> libraries that you can assume are always available on the system.

But you don't know if they are really available or if the *proper*
version of them is available. This might make the whole project
unuseful. And the behaviour of your project while specifying "known"
libraries might just end up being very similar to PyInstaller - without
the embedded interpreter.

Another great issue with Python extensions is usually the ucs2/ucs4
problem; an extension compiled with ucs2 builtin won't work with a ucs4
interpreter and viceversa; that's probably a good reason alone to pack
an interpreter along with the libs.

> The reason libz.so is not included is because it is already required by
> libpython.

I think I can remember it is an optional dependency. If you assume a lib
is available on your interpreter and the user's interpreter has been
compiled in a different way you might just end up with many issues.

> I assume only few projects use dlopen/LoadLibrary/Ex.

This might be an HUGE assumption. Have you verified that? You should at
least look for dlopen() calls in your libraries and prevent building if
that gets used.

Otherwise your code might just unpredicably fail at runtime when the
shared lib is opened.

>> - reproducible builds will be almost impossible - if a dep changes on
>> your system, you might end up without a clear understanding of what
>> happened between one build and another - apparently identical - build.
> 
> As far as I can tell, the same can happen with PyInstaller.
> And the same can happen, as an example, when riverbank builds the PyQt
> installer.

Sure it can happen.

>> My idea is that everything looks far too complex, and would work easily
>> only for really simple cases. Everything else will just turn
>> overcomplicated.
> 
> 
> It is indeed a complex problem, but PyInstaller is far more complex.

But it's already there - why should you reinvent the wheel? Maybe you
can just add some patches on top of it.

Maybe you could just pick a scenario ( Windows XP? Vista? 7? 32-bit
only?) and try to find out a narrow-scoped, quickly-available solution
instead of going for the big, definitive, cross-platform solution. You
might just say "hey, lib A B C are always available on Windows
environments, pack everything else along." . I would keep advising
packing the interpreter as well, by the way.

Very important: I'm not a PyInstaller fan (I've used it a couple of
times), I'd just like to prevent you from doing some work I think is
unnecessary.

-- 
Alan Franzoni
contact me at public@[mysurname].eu