<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><br></div><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><br></div><div>We would need to work with the buildout developers on this. Buildout uses a flat directory full of unzipped eggs, 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><br></div><div>zope.interface is an important package with up-to-date eggs. <a href="https://pypi.python.org/pypi/zope.interface">https://pypi.python.org/pypi/zope.interface</a><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 16, 2016 at 5:41 AM Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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>
_______________________________________________<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/mailman/listinfo/distutils-sig</a><br>
</blockquote></div>