[Distutils] Deprecating little used file types/extensions on PyPI?

Nick Coghlan ncoghlan at gmail.com
Wed Aug 17 01:21:52 EDT 2016

On 17 August 2016 at 01:15, Leonardo Rochael Almeida
<leorochael at gmail.com> wrote:
> PS: In the buildout community, we never really understood the impetus for
> replacing egg as a format, which is really not all that complex and not all
> the different from wheel as it stands, instead of just formalizing it in a
> PEP. We got the feeling that, in the movement of getting rid of setuptools
> as an "installation" dependency, we ended up throwing out the baby with the
> bathwater...

The majority of the problems with eggs are due to the fact that they
were designed to operate *by default* as the plugin management system
for Chandler. buildout uses them in a similar way, so they're a good
fit there.

However, they're *not* a good fit for other cases, hence
"--single-version-externally-managed" and all of the other ways in
which pip switches the defaults to be more developer centric, and less
deployment focused. Most of the problems people ran into with the
defaults were actually related to the way easy_install and
pkg_resources worked rather than due to the egg format itself, but the
lack of clear documentation and specifications meant that the broader
adoption process for programmatic dependency management in general
needed to be based on a more modular reimplementation of similar ideas
with more explicit interoperability interfaces, rather than adopting
the setuptools/easy_install/pkg_resources implementation of those
ideas wholesale.

This means that the situation we've managed to get to now is that we
have wheels as a satisfactory replacement for the "binary
distribution" use case, but we haven't even *tried* to replace eggs
for the "standalone path entry" use case.

That gives us a few options for possible ways forward:

- define a new egg-inspired "*.pypath" format for directories and zip
files that are designed to be placed directly on sys.path, rather than
- just bless eggs as the recommended standalone importable format, and
offer a wheel2egg conversion utility and perhaps an "--as-egg" install
option in pip
- as with the previous, but bake the wheel2egg conversion into
setuptools/easy_install rather than into pip

At least for now, I think that last option probably makes the most
sense, as it moves easy_install, buildout, and other egg based tools
into a similar position to conda, PyPM and the Linux distros: a
downstream community with its own binary distribution format, but
associated tooling to also make it easy for participants in that
ecosystem to consume pre-built wheel files if they want to.

While rebranding eggs (or a close derivative) as "pypath entries"
could help make them more self-explanatory (especially when it comes
to explaining how the zipped form differs from wheel files), doing so
wouldn't actually give us any more architectural flexibility in
practice than the last option.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list