From mrw at twistedmatrix.com  Thu Feb  8 03:01:48 2018
From: mrw at twistedmatrix.com (Mark Williams)
Date: Thu, 8 Feb 2018 00:01:48 -0800
Subject: [Wheel-builders] PEP 571 - manylinux2
Message-ID: <20180208080147.GB16156@alakwan>

Hello, wheel builders!

I had a chat with Geoffrey Thomas about the particulars of symbol
versioning and he reminded me that you all would be interested in a
successor to manylinux1.

Here's the PEP so far:

https://github.com/python/peps/blob/master/pep-0571.rst

And the associated distutils-sig thread:

https://mail.python.org/pipermail/distutils-sig/2018-February/031944.html

(note I sent the first email twice from two different addresses :( The
text of the PEP is the same, so you only have to read one!)

And here are the PRs:

https://github.com/pypa/manylinux/pull/152
https://github.com/pypa/auditwheel/pull/88
https://github.com/pypa/pip/pull/5008

I put initial Docker images up here if you'd like to repair a wheel or
two:

https://hub.docker.com/r/markrwilliams/manylinux2/

Highlights from the distutils-sig thread and pypa/manylinux PR so far:

- Should `manylinux` use CalVer (http://calver.org) ?

- Can the next `manylinux` use newer compilers than `manylinux1`
  without implying backwards incompatibilities?  (The answer is yes -
  explanation forthcoming, thanks to Geoffrey for the help!)

- Should the next `manylinux` drop support for i686?

Please feel free to join the discussion on distutils-sig or comment on
the various PRs.  I look forward to collaborating with everybody!

-- 
  Mark Williams
  mrw at twistedmatrix.com

From ncoghlan at gmail.com  Fri Feb  9 09:09:32 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 10 Feb 2018 00:09:32 +1000
Subject: [Wheel-builders] PEP 571 - manylinux2
In-Reply-To: <20180208080147.GB16156@alakwan>
References: <20180208080147.GB16156@alakwan>
Message-ID: <CADiSq7dtbmNS_yZ3gSirdWOZ_R10muOxX0rmVcbCZ_BKh_iwsQ@mail.gmail.com>

On 8 February 2018 at 18:01, Mark Williams <mrw at twistedmatrix.com> wrote:
> Highlights from the distutils-sig thread and pypa/manylinux PR so far:
>
> - Should `manylinux` use CalVer (http://calver.org) ?

Just noting a subtlety of the CalVer suggestion so folks don't need to
dig it out of the distutils-sig threads: the proposal is to switch
from sequential numbering to instead using the approximate release
year of the library versions specified in the manylinux baseline
(*not* the year when we happen to define any given manylinux variant).

So if manylinux1 had been versioned that way, it would likely have
been either manylinux2006 (based on when glibc 2.5 was released) or
manylinux2007 (based on when RHEL 5 was released).

For PEP 571, the primary marker version is glibc 2.12, and the
reference distro is RHEL(/CentOS 6, giving a proposed variant name of
manylinux2010 (since both glibc 2.12 and RHEL 6.0 were released that
year).

We don't expect this to make much difference for end users (since this
should all be a hidden implementation detail of their package
installer no matter what versioning scheme we use), but for publishers
and tool developers, including the year gives a quick and convenient
reminder of the general vintage of each target baseline.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From mrw at twistedmatrix.com  Sat Feb 10 01:08:21 2018
From: mrw at twistedmatrix.com (Mark Williams)
Date: Fri, 9 Feb 2018 22:08:21 -0800
Subject: [Wheel-builders] PEP 571 - manylinux2
In-Reply-To: <CADiSq7dtbmNS_yZ3gSirdWOZ_R10muOxX0rmVcbCZ_BKh_iwsQ@mail.gmail.com>
References: <20180208080147.GB16156@alakwan>
 <CADiSq7dtbmNS_yZ3gSirdWOZ_R10muOxX0rmVcbCZ_BKh_iwsQ@mail.gmail.com>
Message-ID: <20180210060820.GA11143@alakwan>

On Sat, Feb 10, 2018 at 12:09:32AM +1000, Nick Coghlan wrote:
> On 8 February 2018 at 18:01, Mark Williams <mrw at twistedmatrix.com> wrote:
> > Highlights from the distutils-sig thread and pypa/manylinux PR so far:
> >
> > - Should `manylinux` use CalVer (http://calver.org) ?
> 
> Just noting a subtlety of the CalVer suggestion so folks don't need to
> dig it out of the distutils-sig threads: the proposal is to switch
> from sequential numbering to instead using the approximate release
> year of the library versions specified in the manylinux baseline
> (*not* the year when we happen to define any given manylinux variant).
> 
> So if manylinux1 had been versioned that way, it would likely have
> been either manylinux2006 (based on when glibc 2.5 was released) or
> manylinux2007 (based on when RHEL 5 was released).
> 
> For PEP 571, the primary marker version is glibc 2.12, and the
> reference distro is RHEL(/CentOS 6, giving a proposed variant name of
> manylinux2010 (since both glibc 2.12 and RHEL 6.0 were released that
> year).
> 
> We don't expect this to make much difference for end users (since this
> should all be a hidden implementation detail of their package
> installer no matter what versioning scheme we use), but for publishers
> and tool developers, including the year gives a quick and convenient
> reminder of the general vintage of each target baseline.

Duplicating my response to the CalVer part of the distutils-sig thread
here:

I'm convinced we should use CalVer.

I'm still skeptical of the utility of CalVer here.  Debian 6.0
(squeeze), for example, was released in 2011 but is incompatible with
`manylinux2010` wheels because it uses glibc 2.11.  I'm concerned that
the sooner `manylinux2015` is defined, the more likely it is to
describe too fuzzy an ABI era for CalVer to convey meaningful
information to the LTS audience.

What makes it worth it is the ability to skip and backfill versions.
As you you pointed out, it would be a strange version scheme that had
an architecture that gained wide support in 2015 become `manylinux3`
and one that gained wide support in 2014 `manylinux4`.

In particular, Geoffrey Thomas pointed out that it should be possible
to produce nearly-`manylinux1` compliant wheels with a much newer
toolchain:

https://mail.python.org/pipermail/wheel-builders/2017-July/000283.html

We may decide that an update to `manylinux1` is worthwhile, and by
switching to CalVer, backfilling that version as `manylinux2008` would
be straight forward.

-- 
  Mark Williams
  mrw at twistedmatrix.com

From njs at pobox.com  Tue Feb 27 21:44:34 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Tue, 27 Feb 2018 18:44:34 -0800
Subject: [Wheel-builders] Fwd: Package maintainers, please help test PyPI
In-Reply-To: <695e7861-c9bb-5771-8896-ccdcebe3a741@changeset.nyc>
References: <695e7861-c9bb-5771-8896-ccdcebe3a741@changeset.nyc>
Message-ID: <CAPJVwB=ZAsT7JVVuOxO9z6mQ+o2QUri3TEVVtwFAmA-jw5nY3g@mail.gmail.com>

Hey all - the PyPI rewrite at https://pypi.org has reached the point
where they're looking for package maintainers to try it out and report
bugs; they're also holding office hours on Thursday for questions /
suggestions (or in case you want to help them push it over the finish
line).

-n

---------- Forwarded message ----------
From: Sumana Harihareswara <sh at changeset.nyc>
Date: Mon, Feb 26, 2018 at 8:07 PM
Subject: Package maintainers, please help test PyPI
To: DistUtils mailing list <distutils-sig at python.org>, pypa-dev
<pypa-dev at googlegroups.com>


The Warehouse team has improved the new PyPI, available for you to check
out at https://pypi.org/ , to the point where we would love for package
maintainers to try it out, test it, and give us bug reports.

https://wiki.python.org/psf/WarehousePackageMaintainerTesting has
guidelines, things to test (like user registration and project removal),
and how to contact Warehouse developers.

We're hosting four livechat hours this week where Warehouse maintainers
will be in IRC, in #pypa-dev on Freenode
https://webchat.freenode.net/?channels=#pypa-dev , and specifically
available to talk about problems you run into, or about how to hack on
Warehouse.

    Tuesday Feb 27th: 1700 UTC / noon-1pm EST

    Tuesday Feb 27th: 2300 UTC / 6pm-7pm EST

    Thursday March 1st: 1700 UTC / noon-1pm EST

    Thursday March 1st: 2300 UTC / 6pm-7pm EST


This isn't the big public beta yet, where we really push the message
widely to get non-package-maintainer users to test the site. Since
Warehouse must be a reimplementation of the existing PyPI, please focus
initially on any differences, missing features, or incorrect behavior
that pypi.org exhibits that affect your workflows for account management
and package maintainership. We'll be soliciting feedback on other
concerns soon! Feedback on user experience, accessibility, and overall
ease of use are welcome.

Thanks,
--
Sumana Harihareswara
Warehouse project manager
Changeset Consulting
https://changeset.nyc


-- 
Nathaniel J. Smith -- https://vorpus.org