[Distutils] [Python-Dev] How we can get rid of eggs for 2.6 and beyond

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Phillip J. Eby wrote:
> At 10:17 PM 3/21/2008 +0000, Floris Bruynooghe wrote:
>> On Fri, Mar 21, 2008 at 03:02:25PM -0400, Phillip J. Eby wrote:
>>> At 11:21 AM 3/21/2008 -0500, skip at pobox.com wrote:
>>>>     Joachim> I think, the uninstall should _not_ 'rm -rf' but 
>> only 'rm' the
>>>>     Joachim> files (and 'rmdir' directories, but not recursively) that it
>>>>     Joachim> created, and that have not been modified in the 
>> meantime (after
>>>>     Joachim> the installation).
>>>>
>>>> That's not sufficient.  Suppose file C (e.g. /usr/local/etc/mime.types) is
>>>> in both packages A and B.
>>>>
>>>>     Install A - this will create C
>>>>     Install B - this might overwrite C, saving a copy, or it might retain
>>>>                 A's copy.
>>>>     Uninstall B - this has to know that C is used by A and not touch it
>>> Correct.  However, in practice, B should not touch C, unless the file
>>> is shared between them.
>>>
>>> This is a key issue for support of namespace packages, at least if we
>>> want to avoid using .pth files.  (Which is what setuptools-built
>>> system packages do for namespace packages currently.)
>>>
>>> Of course, one possible solution is for both A and B to depend on a
>>> "virtual package" that contains C, such that both A and B can install
>>> it if it's not there, and list it in their dependencies.  But this is
>>> one of the handful of open issues that needs to be resolved with Real
>>> Life Package Management people, such as Debian, Fedora, etc.
>> Debian (dpkg) does not allow a file to exist in more then one package
>> (distribution in distutils speak) as I said earlier.  Directories can
>> however, they will only be removed if they are empty (i.e. when the
>> last package having that directory is uninstalled).
> 
> This is a general problem with system package managers, 
> actually.  Few allow a file to be provided by more than one package.
> 
>> I'm not familiar with namespace packages as I've never used one, but I
>> assume it is just an empty directory with one (empty?)  __init__.py
>> file in it?
> 
> It's not empty; it has to contain a namespace declaration.  There's 
> another approach that can work around the absence of the __init__.py, 
> by using .pth files, but it's messy, and I'd like to get rid of it if possible.

If all Python distributions which install PythonPacakges under the
"namespace" package are bundeled as DistroPackages, then the content of
__init__.py won't really matter, will it?  There won't be more than one
copy of the "used-to-be namespace pacakge in this scenario.

If it *does* matter (e.g., the DistroPackages need to support use of
non-DistroPackage PythonPackages which use the same namespace), then all
those DistroPackages will need to depend on a nearly-empty,
generated-by-the-packager DistroPacakge which supplies only that file,
as Florian says next.

>>   The only way I can see Debian handling that is by having
>> a Debian package providing exactly that __init__.py and all other
>> Debian packages needing that namespace package will depend on it.
>>
>> However, this is shouldn't worry anyone other then Debian I think.
> 
> Alas, it'll probably affect most package managers.

Right:  RPM isn't happy about having a file owned by multiple packages
either.

>>  If
>> a distribution needs to depend on somthing it will depend on whoever
>> provides the module *inside* the namespace package, not on the
>> namespace itself.  So the fact that no distribution provides the
>> namespace.__init__.py file shouldn't have to worry other users of the
>> python installdb.
> 
> Well, somebody still has to create the __init__.py, and own it for 
> purposes of uninstallation.

I think that will need to be an "artifact" DistroPackage (one which has
no corresponding Python source distribution).

>> Since easy_install and others shouldn't be messing with debian
>> packages in /usr/lib (they should be using /usr/local/lib or
>> ~/.local [1]) this won't be a problem.




- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH5Fyv+gerLs4ltQ4RAsleAKCyF4qz0lULO1J6vAQMNZyaC+MWfQCbBzfD
/eoWYRwwLws24601BAMhdk0=
=dNgJ
-----END PGP SIGNATURE-----