On Jul 17, 2013, at 12:39 PM, Brett Cannon <brett@python.org> wrote:

On Wed, Jul 17, 2013 at 11:46 AM, Daniel Holth <dholth@gmail.com> wrote:

On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon <brett@python.org> wrote:
> I'm going to be pushing an update to one of my projects to PyPI this week
> and so I figured I could use this opportunity to help with patches to the
> User Guide's packaging tutorial.
>
> But to do that I wanted to ask what the current best practices are.
>
> * Are we even close to suggesting wheels for source distributions?

No, wheels don't replace source distributions at all. They just let
you install something without having to have whatever built the wheel
from its sdist. It is currently nice to have them available.

Then I'm thoroughly confused since the Wheel PEP says in its rationale that "Python needs a package format that is easier to install than sdist". That would suggest a wheel would work for a source distribution and replace sdist zip/tar files. If wheels aren't going to replace what sdist spits out as the installation file format of choice for pip what is it for, just binary files alone?

-Brett

You *can* publish only Wheels, especially i your package is pure python. However it's a "built" package. You should still publish the sdist (and sdist 2.0 when that happens) because a Wheel is (essentially) derived from a sdist.

It is easier for the tooling to install and in general you'll want to use them, but not everything supports Wheel and some people will want to build their own wheels. Think of Wheel as a debian package and the sdist as the source package. Ideally the majority of the time people will be installing from the Wheel but the sdist is still there for those who don't.

I'd like to see an ambitious person begin uploading wheels that have
no traditional sdist.

> * Are we promoting (weakly, strongly?) the signing of distributions yet?

No change.

> * Are we saying "use setuptools" for everyone, or still only if you need it
> (asking since there is a stub about installing setuptools but the simple
> example doesn't have a direct need for it ATM, but could use find_packages()
> and such)?

Setuptools is the preferred distutils-derived system. distutils should
no longer be considered morally superior.

The MEBS idea, or a simple setup.py emulator and a contract with the
installer on which commands it will actually call, will eventually let
you do a proper job of choosing build systems.

_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig