<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 12, 2013 at 9:31 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@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 class="im">On 12 February 2013 12:54, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>

> I've learned a lot about packaging in the last year and a half, mostly<br>
> through learning how to deal with the SRPM/RPM toolchain after<br>
> starting with RH. That's actually where I took the<br>
> Archiver->Builder->Installer model from, except that in RPM the spec<br>
> file is still the "one metadata file to rule them all".<br>
</div>[...]<br>
<div class="im">> We could then take a decent run at creating pydist (aka "pysetup v2")<br>
> for Python 3.4 (probably under the distlib banner), which would aim to<br>
> handle the following tasks:<br>
<br>
</div>I would very much like to *not* get bogged down in "grand plans" - as<br>
you say, that way lies failure and burnout.<br>
<br>
My assumptions:<br>
<br>
1. We will have to support projects using setup.py for a long time to<br>
come (probably till Python 4...)<br>
2. Setuptools/distribute is, and will remain, external to the core.<br>
And yet, it offers a short-term way forward (e.g., the wheel project<br>
already provides a bdist_wheel command under setuptools). And external<br>
tools like wheel and pip can provide installers. So the external scene<br>
isn't really a problem.<br>
3. Core support is necessary to give any particular new format<br>
traction and momentum. (That assumption is a bit shaky - eggs imply<br>
otherwise, but sadly wheel isn't getting much take-up on its own).<br>
4. The core is the place for enabling technology/libraries, and<br>
reference implementations of standards.<br>
5. The wheel binary format is a key piece in any new infrastructure<br>
(it's key for me, anyway)<br>
<br>
Based on this, the things I consider important are:<br>
<br>
1. Getting something like distlib into the core, to provide the<br>
canonical implementation of the key things that packaging tools<br>
require. [1]<br>
2. Providing tools in the core to take an existing, functional,<br>
distribution (using setup.py) and build a wheel. (This is a<br>
"political" goal more than anything - distribute/wheel is the<br>
practical solution right now, but having wheel support in the core<br>
sends a specific message that it *is* the standard format). I see no<br>
value in this being spelled anything other than "python setup.py<br>
bdist_wheel". [2]<br>
3. Providing a minimal wheel installer in the core. Same logic. I have<br>
one already that I would be happy to contribute. [3]<br>
4. A PEP376 based uninstaller in the core. Not so much because we need<br>
an uninstaller, but again simply to assert clearly that the Python<br>
core supports the PEP. In particular, as an encouragement for external<br>
tools like distribute and pip to adopt the dist-info format over the<br>
older egg-info one.<br>
5. I hadn't thought of this one myself, but I'd like to see the sdist<br>
format documented and standardised as Nick suggested. It goes without<br>
saying that "python setup.py sdist" should produce standard format<br>
sdists.<br>
<br>
[1] Whether those tools consider it worth the effort to remove their<br>
own code and use the core in its place is not so important, as it<br>
relates to support of older versions which isn't a core concern - but<br>
the tools would have to ensure that they *behave* the same as the core<br>
code.<br>
[2] Whether the distribute/wheel implementation of bdist_wheel clashes<br>
with this is something that needs to be considered, but I doubt it'll<br>
be a big problem in practice.<br>
[3] It does not depend on the wheel project, although I did copy some<br>
code from the wheel project, so we'd need Daniel's agreement to use<br>
it.<br>
<br>
Paul<br>
<br>
PS Even with all of the above, I don't know if the wheel format will<br>
"take off". I'd like to see the PyPI infrastructure offer a means of<br>
enabling people taking the role of "builder", and taking existing<br>
source packages and uploading binary builds (in wheel format,<br>
naturally :-)) which can be used by the likes of pip. Everyone<br>
building their own local archive is wasteful. But that's a whole other<br>
debate that I have neither the time nor the energy to get involved<br>
in...<br></blockquote><div><br></div><div>Yes you have my permission to put wheel infrastructure in core. Just do a good job at it :-)<br></div><div><br></div><div>I don't know whether wheel is "taking off" or if it has to. Jannis has asked me to PEP-ify it in order to get the installer support merged into pip.  Once that happens I suppose the format will become more popular.<br>
<br></div><div>The existing wheel users are getting along fine without a large number of pre-built wheels. The pip implementation is designed to make it very easy to cache a virtualenv's worth of packages as wheels, and when you want to duplicate the virtualenv you don't have to continually re-build.<br>
</div><div>The format makes new-virtualenv-per-deploy workflows much, much faster and more predictable.<br><br><pre># Build a directory of wheels for pyramid and all its dependencies
pip wheel --wheel-dir=/tmp/wheelhouse pyramid

# Install from cached wheels
pip install --use-wheel --no-index --find-links=/tmp/wheelhouse pyramid</pre></div></div></div></div>