[Distutils] PEP 426 updated (with more than you ever wanted to know about version schemes)

[Daniel Holth]

On Tue, Feb 12, 2013 at 11:13 AM, Ronald Oussoren <ronaldoussoren at mac.com>wrote:

>
> On 12 Feb, 2013, at 16:55, Daniel Holth <dholth at gmail.com> wrote:
>
> On Tue, Feb 12, 2013 at 10:04 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>>
>> On 13 Feb 2013 00:55, "Ronald Oussoren" <ronaldoussoren at mac.com> wrote:
>> >
>> >
>> > On 12 Feb, 2013, at 14:46, Daniel Holth <dholth at gmail.com> wrote:
>> > >
>> > >
>> > > I still think it makes more sense to just download distribute and
>> wheel when you want to build one, but to each his own... if you need to
>> create packages for pypi without being able to install things from it,
>> knock yourself out.
>> >
>> > Why the hostility? It makes sense to have basic support in the stdlib.
>>
>> I'm playing a much longer game than Daniel - when you're thinking in
>> terms of the next few months, then the PEPs are only significant because
>> the pip folks (sensibly, IMO) have made that a condition of merging wheel
>> support (at which point people will naturally start using them more, since
>> they won't have to seek them out, pip will cache the built wheels
>> automatically)
>>
>> Core support only starts to matter once you're thinking in terms of
>> *years*, and the way beginners will encounter Python's distribution
>> ecosystem in 3.4+ :)
>>
> +1 although I need to finish the PEP before then, the core support should
> take years. This gives the community time to discover a good system.
>
>
> Ehmm.... the plan that slowly gets clear is to split the packaging related
> functionality in at least two parts: building a wheel from an sdist, and
> installing the wheel. Teaching distutils to create wheels (including modern
> metadata), adding a wheel installer (see earlier mails by Nick) and
> describing a standard mechanism for invoking wheel creation (such as the
> sdist2wheel.py script in a earlier mail by Nick) should take years to get
> right.
>
> When those parts are present it will be a lot easier to experiment with
> other toolsets for building wheels, and getting that right may wel take a
> long time and doesn't have to be shoehorned into python's release schedule.
>

That's the plan. In the meantime you can enjoy compiling lxml only once by
using non-core packaging tools.

BTW. the discusion on how to secure package distribution might affect the
> wheel format, in particular the digital signature part. I wouldn't push for
> acceptence of the wheel PEP before that discussion settles down a bit.
>

I wouldn't worry about that; wheel's (now fully optional) embedded
signatures format should not have any more impact on the secure pypi
discussion than pypi's current detached GPG signature support does. It is a
useful feature to me and will remain so even/especially if you are not
using pypi at all.

Besides that if embedded signatures wind up being part of the secured pypi
system you would have to define them for sdist formats as well. It's not
directly related to binary packaging.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130212/450cf4a2/attachment-0001.html>