[Distutils] how to easily consume just the parts of eggs that are good for you

[Stanley A. Klein]

On Wed, April 9, 2008 12:41 am, Phillip J. Eby wrote:
> At 10:49 PM 4/8/2008 -0400, Stanley A. Klein wrote:
>>On Tue, April 8, 2008 9:37 pm, Ben Finney
>><bignose+hates-spam at benfinney.id.au> wrote:
>> > Date: Wed, 09 Apr 2008 11:37:07 +1000
>> > From: Ben Finney <bignose+hates-spam at benfinney.id.au>
>> > Subject: Re: [Distutils] how to easily consume just the parts of eggs
>> >       that    are     good for you
>> > To: Distutils-Sig at Python.Org
>> >
>> >
>> > zooko <zooko at zooko.com> writes:
>> >> eyes and said "So they are planning to reinvent apt!".
>> >
>> > That's pretty much my reaction, too.
>>
>>I have the same reaction.
>
> I'm curious.  Have any of you actually read PEP 262 in any detail?  I
> have seen precious little discussion so far that doesn't appear to be
> based on significant misunderstandings of either the purpose of
> reviving the PEP, or the mechanics of its proposed implementation.

I haven't read the PEP at all.  I generally don't read PEP's.

>
>
>>I have tried in the past to use easy_install, but have run into problems
>>because there is no communication between easy_install and the rpm
>>database, resulting in failure of easy_install to recognize that
>>dependencies have already been installed using rpms.
>
> This problem doesn't exist with Python 2.5, unless you're using a
> platform that willfully strips out the installation information that
> Python 2.5 provides for these packages.
>

IIRC, I have had the problem with Python 2.5 on Fedora 7.  Until recently,
Fedora packagers did strip out the egg information included with Python
packages they packaged.  I left those files in when packaging myself using
bdist_rpm.

However, are you implying that the installation information for Python egg
packages accesses and coordinates with the rpm database?  I found myself
having to go into the setup.py for the relevant package(s) and delete any
statements regarding dependencies.  Otherwise, IIRC, the packaging
couldn't proceed because the Python packaging tool couldn't find the
dependencies that had already been installed as rpms.  After installation,
Python managed to find the relevant files, but the packaging tool
couldn't.

>
>>A database focused only on Python packages is highly inappropriate for
>>Linux systems, violates the Linux standards, and creates problems because
>>eggs are not coordinated with the operating system package manager.
>
> The revamp of PEP 262 is aimed at removing .egg files and directories
> from the process, by allowing system packagers to tell Python what
> files belong to them and should not be messed with.  And conversely,
> allowing systems and installation targets *without* package managers
> to safely manage their Python installations.

IMHO, the main system without a package manager is Windows.  A reasonable
way to deal with Windows would be to create a package manager for it that
could be used by Python and anyone else who wanted to use it.  The package
manager could establish a file hierarchy similar to the Unix FHS and
install files appropriately, except for what is needed to satisfy the
Windows OS.  That would probably go a long way to addressing the issues
being discussed here.  This is primarily a Windows problem, not a Python
problem.


>
>
>>   The
>>way to achieve a database for Python would be to provide tools for
>>conversion of eggs to rpms and debs,
>
> Such tools already exist, although the conversion takes place from
> source distributions rather than egg distributions.
>

You are talking here about bdist_rpm and not about a tool that would take
a Python package distributed as an egg file and convert the egg to an rpm
or a deb.  Unfortunately, some Python packagers are beginning to limit
their focus only to egg distribution.  That creates a problem for users
who have native operating system package management.

>
>>to have eggs support conformance to
>>the LSB and FHS,
>
> Applying LSB and FHS to the innards of Python packages makes as much
> sense as applying them to the contents of Java .jar files -- i.e.,
> none.  If it's unchanging data that's part of a program or library,
> then it's a program or library, just like static data declared in a C
> program or library.  Whether the file extension is .py, .so, or even
> .png is irrelevant.

The FHS defines places to put specific kinds of files, such as command
scripts (/bin, /usr/bin, /sbin, or /usr/sbin), documentation
(/usr/share/doc/package-name), and configuration files (/etc).  There are
several kinds of files identified and places defined to put them. 
Distribution by eggs has a tendency to scoop up all of those files and put
them in /usr/lib/python/site-packages, regardless of where they belong. 
Having eggs support conformance to FHS would mean recognizing and tagging
the relevant files.  A tool for converting eggs to rpms or debs would
essentially reformat the egg to rpm or deb and put files where they
belong.


Stan Klein