<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 24, 2016 at 1:28 PM Leonardo Rochael Almeida <<a href="mailto:leorochael@gmail.com">leorochael@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 24 August 2016 at 12:56, Daniel Holth <span dir="ltr"><<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>></span> wrote:<br></div></div></div><div dir="ltr"><div class="gmail_extra"><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"><div dir="ltr"><div class="gmail_quote"><span><div dir="ltr">On Wed, Aug 24, 2016 at 10:41 AM Alex Grönholm <<a href="mailto:alex.gronholm@nextday.fi" target="_blank">alex.gronholm@nextday.fi</a>> wrote:<br></div></span></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><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"><div dir="ltr"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">[...]</div></blockquote></span></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><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"><div dir="ltr"><div class="gmail_quote"><div><br></div><div><div style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><div style="border-left:1px solid rgb(224,224,224);color:rgb(117,117,117);padding:10px"><div bgcolor="#FFFFFF"><span>19.08.2016, 20:25, Daniel Holth kirjoitti:<br></span><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Eggs are the only way to add a zipped distribution to PYTHONPATH and have setuptools find the metadata (the Python code can be found with or without the metadata; setuptools does not discover *.dist-info inside zip). Eggs are used by buildout, especially in the unzipped into a directory form. And they could still be used for their originally designed use as a plugin format.</div></blockquote></div></div></div><div style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><div><div bgcolor="#FFFFFF" style="font-size:13px"><span style="line-height:1.5">Alex kirjoitti: "What is not clear to me is who needs this. Is this not what virtualenvs are for? Or could wheels not be used for the same purpose? What am I missing?"</span></div></div></div></div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><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"><div dir="ltr"><div class="gmail_quote"></div></div></blockquote><div><br></div><div>There is some mixing of concerns here, but to clarify: wheels in general CANNOT be blindly dropped on PYTHONPATH and be expected to work.</div><div><br></div><div>Only wheels that DO NOT contain an entry like `wheel_name-1.0.data/purelib` or `wheel_name-1.0.data/platlib` can be dropped on PYTHONPATH to make their code available to a python process.</div><div><br></div><div>But that only works for python code. `setuptools`/`pkg_resources` will currently be unable to read entry points (in particular, console_scripts) from such wheels dropped in the PYTHONPATH.</div><div><br></div><div>So, they cannot be used in general for the purpose of dropping them on the PYTHONPATH. But the buildout communities (incl. Plone) do not exactly require wheels dropped on the PYTHONPATH. See belowÇ</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 class="gmail_quote"><div style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif"><div bgcolor="#FFFFFF" style="font-size:13px"><span style="font-size:small">What you are missing is that while they could in theory be used for the same purpose, in practice there is a large group of Plone & buildout users who are not using wheels for that. (And the wheels would have to be unzipped into their own individual directories, but buildout almost always unzips eggs lately too.)</span></div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>In particular, buildout users on Windows, who cannot easily compile sdists that contain C extensions and which are currently uploaded as eggs to PyPI (see lxml and zope.interface as examples of highly used packages in this regard).</div><div><br></div><div>As for wheels, not only would these wheels have to be unzipped, but their `purelib`/`platlib` contents, if present, copied to the "root" of where they were unpacked, and the `wheel_name-1.0.dist-info` directory renamed to `EGG-INFO`</div></div></div></div></blockquote><div><br></div><div>pkg_resources has been able to present an identical interface to EGG-INFO and dist-info directories for longer than pip has known about wheels. Entry points will also work fine. buildout would of course have to generate the console_scripts, which it always does anyway.</div><div><br></div><div>Does anyone have an example of how to produce wheels with both purelib and platlib using setuptools?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>But the most important thing of all, these wheels would have to participate in the dependency resolution of other packages along with sdists in the middle of a buildout run.</div></div></div></div></blockquote><div> </div><div>Yes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The last aspect means that having a canonical piece of code that knows how to pick up a wheel from PyPI and unpack it correctly somewhere in the PYTHONPATH is not enough.</div><div><br></div><div>(and nobody has offered such canonical a piece of software yet, except the not really useful "call out to pip as a subprocess").</div><div><br></div><div>What is needed is for setuptools to be modified to treat wheels the same way it currently treats bdist_wininst files for installation: as a binary lump that it knows how to download from PyPI, unpack and convert into an egg.</div><div><br></div><div>On the other hand, if the above happens, we can block .egg files from upload to PyPI along with the rest of the formats. Wouldn't it be nice?</div><div><br></div><div>Any other option for adding wheels support to buildout (calling out to pip, using distlib,... ) will involve either a lot of code rewrite [1] or the need to rewrite many currently functioning buildout configurations [2].</div><div><br></div><div>[1] to make the `zc.recipe.egg` part of buildout behave exactly like it was still using setuptools, and pkg_resources would still need to be taught how to read .dist-info directories.</div><div>[2] to use something else than `zc.recipe.egg` to install Python packages</div><div><br></div></div><br></div></div>
</blockquote></div></div>