<div dir="ltr">Thanks Daniel,<div><br></div><div>A few corrections and considerations below:</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On 16 August 2016 at 09:50, Daniel Holth <span dir="ltr"><<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Wheel should be updated to support the egg use case before egg is removed. IIUC this would mostly mean officially supporting 'unzipped wheel' as a thing you can add to PYTHONPATH, possibly with some additional restrictions for the specific wheel. We could go a little further and officially support zipped wheels "if zip safe". We could implement wheel2egg to complement egg2wheel?</div></blockquote><div><br></div><div>Specifically, buildout right now has setuptools as its only dependence, and buildout uses it to locate, download and build sdist dependencies, or directly download and use .egg dependencies, which are important for Windows platforms in the communities that use buildout and depend on compiled extensions.<br></div><div><br></div><div>It also uses setuptools for reading entry points of packages for internal use (buildout recipes and extensions), and for figuring out console scripts to install in "bin"</div><div><br></div><div>(this last part is actually the job of the `zc.recipe.egg` recipe, which is buildout's pip replacement that predates pip by a few years, but it's the only recipe that is developed in the same repo as buildout itself, so we'll treat them as one for this discussion).<br></div><div><br></div><div>This also means that so far buildout has been missing out on wheels. It hasn't been much of a problem since almost all packages also have an sdist that can be turned into an egg by setuptools, but if the trend of sdist-less wheels increases, this could quickly become a problem.</div><div><br></div><div>It also means that, buildout is missing out on manylinux...</div><div><br></div><div>A wheel2egg might be nice, but unless it's integrated into setuptools proper, it would mean adding another dependency to buildout and the developers would rather depend on a single library for talking to PyPI and making packages appear as "directories addable to `sys.path`.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The main reason wheel did not support these use cases from the beginning is that it was quicker not to. Also, it is a bit confusing for 'unzipped directory in the (egg/wheel) format', 'archive', and 'plugin you add to PYTHONPATH' to all have the same name 'eggs'.<br></div><div><div><br></div><div>We would need to work with the buildout developers on this. Buildout uses a flat directory full of unzipped eggs</div></div></div></blockquote><div><br></div><div>Not necessarily unzipped. Although buildout unzips all sdists and eggs it installs, if it's in the "eggs" directory, has the right name (e.g. suds_jurko-0.6-py2.7.egg), and can be added to sys.path, that's all buildout cares about, but if it's not yet there, buildout will use setuptools to install it as an "unzipped egg" (there used to be a switch to install eggs as zipped, or rather, as unzipped, zipped being the default, but nobody liked the eggs zipped so they threw that foot gun away).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>, not exactly the uploading to pypi case, and when installing console_scripts, makes sure the necessary eggs are added to sys.path in the script itself. The exact mechanism varies depending on the version of buildout used.<br></div></div></div></blockquote><div><br></div><div>This hasn't changed for a while. The mechanism is, basically, to create a script in "bin/" that appends all (recursive) dependencies of the script from the "eggs" directory into `sys.path` then call the entry point declared in the `console_scripts`.</div><div><br></div><div>The buildout configuration can specify both the name that the console scripts will be installed, and also specify some code to be run immediately before the entry point,  which is useful for pre-setting command line arguments, for example. All of this is done using setuptools APIs.</div><div><br></div><div>This and the fact that buildout has a plethora of extensions and powerful declarative configuration language that allows for dependency management between different "parts" of the configuration (e.g. coordinating ports and addresses between services like Varnish and Plone, or adding the paths of the script and configuation file from Plone into a supervisord configuration) means that, like many things coming out of the brilliant mind of Jim Fulton, it's considered overly complex by many, but those who use it would find it rather difficult to replace if it's no longer functional.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>zope.interface is an important package with up-to-date eggs. <a href="https://pypi.python.org/pypi/zope.interface" target="_blank">https://pypi.python.org/pypi/<wbr>zope.interface</a></div></div></div></div></div></blockquote><div><br></div><div>And it's used by Plone and Pyramid, to mention two mainstream communities that would be affected by a lack of binary eggs on Windows, for example.</div><div><br></div><div>To sumarize, if we could convince setuptools to treat wheels on PyPI for download and installation the same way it treats eggs, or if we could replace setuptools with something that did, then buildout would be onboard the deprecation of eggs.</div><div><br></div><div>Cheers,</div><div><br></div><div>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...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><span style="color:rgb(80,0,80)">On Tue, Aug 16, 2016 at 5:41 AM Paul Moore <</span><a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a><span style="color:rgb(80,0,80)">> wrote:</span><br></div></div></div></div></div><div class=""><div class="h5"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 15 August 2016 at 20:09, Donald Stufft <<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>> wrote:<br>
><br>
> First off, we currently allow people to upload sdist, bdist_wheel, bdist_egg,<br>
> bdist_dmg, bdist_dumb, bdist_msi, bdist_rpm, and bdist_wininst. However I think<br>
> that we should try to get rid of support for most of these. Just for reference<br>
> currently the number of files uploaded for each type of file looks like:<br>
><br>
> * sdist: 506,585<br>
> * bdist_wheel: 81,207<br>
> * bdist_egg: 48,282<br>
> * bdist_wininst: 14,002<br>
> * bdist_dumb: 5,502<br>
> * bdist_msi: 497<br>
> * bdist_rpm: 464<br>
> * bdist_dmg: 45<br>
><br>
> Out of all of these, I think that we can easily remove bdist_dmg, bdist_rpm,<br>
> and bdist_dumb. I also believe that there is a strong case for removing<br>
> bdist_msi and bdist_wininst. I also think we should consider removing<br>
> bdist_egg.<br>
<br>
Overall +1 from me for this.<br>
<br>
Some thoughts:<br>
<br>
1. It would be nice to provide some transition process for the<br>
bdist_wininst case, as these are automatically convertible (with some<br>
caveats) to wheel using "wheel convert". I'm not suggesting that we do<br>
an auto-convert, but a way of getting the message out to projects that<br>
use wininst that there is a migration path might be worth it (although<br>
it's equally possible that the projects in question are all<br>
unmaintained, in which case there's not much point in bothering).<br>
2. Do we understand the remaining use cases for eggs? AIUI, buildout<br>
uses it, and I get the impression that there are other specialist<br>
groups that still use the egg format (the plone community?). While I<br>
don't think having two binary distribution formats is good for the<br>
ecosystem (it's confusing for users, and splits effort), I think we<br>
should be make sure we have those use cases covered (or at least have<br>
a plan on how we handle the situation) before deprecating the egg<br>
format.<br>
<br>
Paul<br>
______________________________<wbr>_________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/distutils-sig</a><br>
</blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/distutils-sig</a><br>
<br></blockquote></div><br></div></div>