[Distutils] [RFC] eggbuild

[Alan Franzoni]

On 11/4/10 7:25 PM, Manlio Perillo wrote:
>> What specific problem are you trying to address?
> 
> 
> Distribute a Python package on Windows.
> 
> Suppose package A depends on pure Python package B and on PyQT.
> Right now I have two options:
> 
> 1) create an installer using PyInstaller or py2exe
> 2) have the user install Python (not a problem), PyQt
>   (the "all included" installer) and then easy_install my application
> 
> 
> I think this is a big problem.
> Even if we assume that it is ok to create a PyInstaller installer, I
> don't see why a Windows user must not be able to do:
>     easy_install A
> 
> and have B and PyQt (with external libraries) correctly installed on the
> system.


OK, I got it.

I must admit that my knowledge of Windows is not advanced enough to tell
you whether this could work or if there're obvious issues.

This could be a problem on Linux as well, by the way. If I try
installing, let's say, lxml, and libxml2 and libxml2-dev are not
installed on my system, easy_install will fail.

Those are my 2c for the "weak spots":

- you need to check recursively for all the shared libraries needed by
python modules and extensions, and all the shared libraries needed by
those shared libraries, and so on. Eggbuilds might end up just like huge
chroots.

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?

I've just checked for your EGG-INFO/native_libs: you don't seem to
recurse libraries. Just an example I spotted: libgnutls requires zlib,
but no libz.so.something is included in native libs.

- you need to check for dlopen() calls as well (or LoadLibrary/Ex on
Windows - but I don't know whether it's easy to look for them in PE
executables or DLLs); this might not be trivial and will increase the
number of libraries that need to be included.


- there might be legal implications when redistributing shared
libraries; it might not be easy to tell which license each library has,
and a single non-redistributable library might prevent to release the
whole package. GPL and LGPL mandates source distribution along binary
distribution, are you ready to package and make all the sources
available to the user? Remember that, as you will be the redistributor,
this requirement must be met by you - you can't just tell people to
fetch sources from this or that environment.

- 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.
You may resort to chroot-building tools like pbuilder or mock on Linux,
but this will be far more difficult on Windows.

My idea is that everything looks far too complex, and would work easily
only for really simple cases. Everything else will just turn
overcomplicated.

You're really trying to port to Python what Java does through its
classpath system and, to a greater extent, with Osgi; but Python
philosophy is quite different, you'll end up distributing whole OSes!


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