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

Nathaniel Smith njs at pobox.com
Thu Aug 18 18:10:43 EDT 2016


On Tue, Aug 16, 2016 at 10:21 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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
> installed
> - 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

I'm not at all familiar with buildout's internals, but from the
description upthread it sounds like it already has to have fairly
intimate knowledge of and control over the layout of the directory
it's managing (so that it can do things like generate sys.path
manipulation code inside console scripts, etc).

Would it make sense to declare that buildout has its own directory
layout and conventions that it uses (which happen to be suspiciously
similar to the legacy .egg format), and that buildout is responsible
for figuring out how to consume standardized formats like .whl and put
them into the layout it wants? I don't think there's much appetite for
trying to standardize .egg, and the advantage is that it moves control
of the format to the people who actually use it -- distutils-sig is
not really the best place to be trying to do anything with eggs at
this point AFAICT. It might even make sense to split out some bits of
setuptools into buildout.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org


More information about the Distutils-SIG mailing list