On 17 August 2016 at 01:15, Leonardo Rochael Almeida <leoroch...@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 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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
