[Python-Dev] PEP 376

[Łukasz Langa]

On 2009-06-22 at 14:23, Tarek Ziadé wrote:

> Hello,
>
> We have polished out PEP 376 and its code prototype at Distutils-SIG.
> It seems to fullfill now all the requirements,
> so I am mailing it here again, for a new round of feedback, if needed.


Hello.
I have read the current version of the PEP from trunk and would like  
to make some comments about it.

The .egg-info as a directory
============================
At our company, after much fiddling about the current distutils and  
setuptools, we have developed a solution that enables us to serve  
pseudo-eggs. What I mean by that is that by plugging into the PEP 302  
infrastructure, we were able to make non-filesystem-based repositories  
behave like `.egg` files. There are a couple of use cases for that  
implementation, the most important ones being:
* being able to deploy encrypted and sealed blobs with a binary  
loader, to discourage fiddling around the source code by its users
* being able to serve modules from a database back-end instead of the  
filesystem

This solution depends on the `EGG-INFO` to be fetched from the `.egg`  
itself. We wouldn't want to use a static filesystem-based folder  
because it breaks the encryption use-case by revealing the  
`SOURCES.txt` information. It also breaks the database back-end  
usecase by presenting static versioning information whereas the whole  
point of using a database backed "egg" is to have the newest version  
installed at all times.

Moreover, the proposed ``egginfo_dirname()`` routine is a step-back  
from the ``pkg_resources`` approach where we don't enforce resources  
to reside on a traditional filesystem.

The uninstall feature
=====================
This is a great feature but I don't seem to understand why there seems  
to be a consensus here that it's good for it not to even warn about  
dependencies, let alone manage them. ``easy_install`` and co. does  
manage dependencies while installing, why shouldn't it be symmetrical  
in that regard? Moreover, wouldn't dependency management be useful  
while using ``easy_install`` to *upgrade* an installation of a package?

The second issue is that while having ``python -m  
distutils.uninstall`` is the preferred way to go, I would argue that  
enabling an ``uninstall`` entry-point in ``setup.py`` is desirable as  
well, if only for retaining an intuitive symmetrical system where I  
can do ``python setup.py install`` and ``python setup.py uninstall``  
as well. I'm not forced to download the sources just to uninstall the  
package (``distutils.uninstall`` covers this use case) but if I do  
have the source code available, it would feel very natural to use the  
``setup.py`` provided.

There already is the precedent of ``setup.py develop --uninstall``.  
Having a ``setup.py uninstall`` could handle this use case as well.

More high-level remarks
=======================
This isn't probably the best place to cover this but may serve as a  
rationale for the above .egg-info problems we have with the proposed  
changes.

It's great that you push the metadata functionality to core distutils.  
At the same time, it would be feasible to think over the whole `egg`  
concept. We would argue that having the `egg` format as a container  
more-less agnostic to the underlying data storage structure would be  
**very** useful. Imagine installable `egg` support packages which  
would enable you to:
* use other compression formats beside ZIP
* use other means of module storage beside the filesystem
* use sealed and encrypted archives for deployment
* use programmatic `egg`s for licensing, etc.
* ``easy_install`` from different protocols, archive formats, etc.

Decoupling the `egg` format from the concrete "zip-based" or  
"directory-based" implementations is a step forward in that direction.  
In that regard, the solution PEP 376 is proposing isn't ultimately  
solving the issues we're having.

Thanks for your time.

-- 
Best regards,
Łukasz Langa
Senior Developer
STX-Next Sp. z o.o.
tel: +48 791 080 144
skype: lukaszlanga