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