Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #12538 > unrolled thread

Python Wheel Related Policy Change

Back to article view | Back to linux.debian.maint.python

Contents

  Python Wheel Related Policy Change Scott Kitterman <debian@kitterman.com> - 2020-04-30 05:30 +0200
    Re: Python Wheel Related Policy Change Matthias Klose <doko@debian.org> - 2020-04-30 09:30 +0200
      Re: Python Wheel Related Policy Change Scott Kitterman <debian@kitterman.com> - 2020-04-30 12:00 +0200
        Re: Python Wheel Related Policy Change Scott Kitterman <debian@kitterman.com> - 2020-04-30 18:30 +0200
          Re: Python Wheel Related Policy Change Stefano Rivera <stefanor@debian.org> - 2020-04-30 20:40 +0200
            Re: Python Wheel Related Policy Change Scott Kitterman <debian@kitterman.com> - 2020-04-30 22:40 +0200
              Re: Python Wheel Related Policy Change Stefano Rivera <stefanor@debian.org> - 2020-04-30 23:50 +0200
                Re: Python Wheel Related Policy Change Scott Kitterman <debian@kitterman.com> - 2020-05-01 00:30 +0200
                  Re: Python Wheel Related Policy Change Scott Kitterman <debian@kitterman.com> - 2020-05-01 22:50 +0200
                  Re: Python Wheel Related Policy Change Nicholas D Steeves <nsteeves@gmail.com> - 2020-05-01 23:10 +0200

#12538 — Python Wheel Related Policy Change

[Multipart message — attachments visible in raw view] — view raw

I think Python policy changes should be discussed.  I accidentally committed a 
change to git [1] (I didn't realize I still had access, I thought it would be 
a merge request) to allow Python 3 only wheels for packages that require 
wheels, but that no longer support Python 2.  This is going to happen the next 
time I upload python-pip since the current version of setuptools is python3 
only.

Hopefully this won't be controversial.  There's really no way to avoid it.

Scott K

[1] https://salsa.debian.org/cpython-team/python3-defaults/-/commit/
92e10578994c1950e0c98387a60fdcfa4c69e1d4

[toc] | [next] | [standalone]

#12539

On 4/30/20 5:28 AM, Scott Kitterman wrote:
> I think Python policy changes should be discussed.  I accidentally committed a 
> change to git [1] (I didn't realize I still had access, I thought it would be 
> a merge request) to allow Python 3 only wheels for packages that require 
> wheels, but that no longer support Python 2.  This is going to happen the next 
> time I upload python-pip since the current version of setuptools is python3 
> only.

this is not true. python-setuptools is still built from the source packages
python-setuptools.  Is there a reason that you cannot use it?

> Hopefully this won't be controversial.  There's really no way to avoid it.

well, better don't assume that.

Matthias

[toc] | [prev] | [next] | [standalone]

#12540

On April 30, 2020 7:21:39 AM UTC, Matthias Klose <doko@debian.org> wrote:
>On 4/30/20 5:28 AM, Scott Kitterman wrote:
>> I think Python policy changes should be discussed.  I accidentally
>committed a 
>> change to git [1] (I didn't realize I still had access, I thought it
>would be 
>> a merge request) to allow Python 3 only wheels for packages that
>require 
>> wheels, but that no longer support Python 2.  This is going to happen
>the next 
>> time I upload python-pip since the current version of setuptools is
>python3 
>> only.
>
>this is not true. python-setuptools is still built from the source
>packages
>python-setuptools.  Is there a reason that you cannot use it?

In the short run, the blocker is that dirtbike doesn't support it.  In the longer run I think adding back python2 dependencies is not a good idea.

At best it's a short-term avoidance mechanism.

>> Hopefully this won't be controversial.  There's really no way to
>> avoid it.
>
>well, better don't assume that.

It's true that there is a short-term alternative, but I think it's a waste of effort to try and implement it.  At most it only buys you until the next pip vendored lib that we unbundle as a wheel goes python3 only.

Are you volunteering to rewrite dirtbike so it can make a universal wheel from python-setuptools?

Personally, I'm not interested.  If you add the word reasonable to my original statement, I stand bye it.  

Scott K

[toc] | [prev] | [next] | [standalone]

#12542

[Multipart message — attachments visible in raw view] — view raw

On Thursday, April 30, 2020 5:53:33 AM EDT Scott Kitterman wrote:
> On April 30, 2020 7:21:39 AM UTC, Matthias Klose <doko@debian.org> wrote:
> >On 4/30/20 5:28 AM, Scott Kitterman wrote:
> >> I think Python policy changes should be discussed.  I accidentally
> >committed a
> >> change to git [1] (I didn't realize I still had access, I thought it
> >would be
> >> a merge request) to allow Python 3 only wheels for packages that
> >require
> >> wheels, but that no longer support Python 2.  This is going to happen
> >the next
> >> time I upload python-pip since the current version of setuptools is
> >python3
> >> only.
> >
> >this is not true. python-setuptools is still built from the source
> >packages
> >python-setuptools.  Is there a reason that you cannot use it?
> 
> In the short run, the blocker is that dirtbike doesn't support it.  In the
> longer run I think adding back python2 dependencies is not a good idea.
> 
> At best it's a short-term avoidance mechanism.
> 
> >> Hopefully this won't be controversial.  There's really no way to
> >> avoid it.
> >
> >well, better don't assume that.
> 
> It's true that there is a short-term alternative, but I think it's a waste
> of effort to try and implement it.  At most it only buys you until the next
> pip vendored lib that we unbundle as a wheel goes python3 only.
> 
> Are you volunteering to rewrite dirtbike so it can make a universal wheel
> from python-setuptools?
> 
> Personally, I'm not interested.  If you add the word reasonable to my
> original statement, I stand by it.

Making dirtbike build a py3 wheel for setuptools (and pkg_resources), which is 
technically accurate at this point since dirtbike can't build wheels from a 
python2 package was trivial to do:

 dirtbike/__init__.py | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Three of the five insertions were comment.

If someone wants to provide a patch to dirtbike so it can also build wheels 
from python-setuptools and python-pkg-resources, then we could add then to 
build-depends and provide both a set of py2 wheels and py3 wheels for as long 
as they are in the archive.

It still needs the Python policy change since they aren't universal, but it 
would allow setuptools to keep up for python3 in pip without dropping the 
local wheels from python2.  We also have ipaddr back in the archive to support 
wheeling it so pip will run with python2.

I think that would be the best technical approach for now, but I don't have 
time at the moment to proceed further.  Contributions welcome.  

I'd like to resolve this one way or the other because as it stands, the next 
python-pip upload will make wheels from python3-setuptools and python3-pkg-
resources that are formatted as universal wheels, but aren't in terms of 
content. 

I've started working on packaging pip 20.1.  Once I have it ready to go, I'll 
upload dirtbike either as it stands or with support for making python2 wheels 
if someone provides it.  Just uploading pip using the current dirtbike is not 
appropriate.

Scott K

[toc] | [prev] | [next] | [standalone]

#12543

Hi Scott (2020.04.30_16:23:41_+0000)
> Making dirtbike build a py3 wheel for setuptools (and pkg_resources), which is 
> technically accurate at this point since dirtbike can't build wheels from a 
> python2 package was trivial to do:
> 
>  dirtbike/__init__.py | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> Three of the five insertions were comment.

That seems reasonable, although if we're going down that road, it
probably makes no sense for any of them to be universal.

> If someone wants to provide a patch to dirtbike so it can also build wheels 
> from python-setuptools and python-pkg-resources, then we could add then to 
> build-depends and provide both a set of py2 wheels and py3 wheels for as long 
> as they are in the archive.

The window for doing this is probably closing, too.

I hacked this in Ubuntu 20.04, just before release:
https://launchpadlibrarian.net/475592029/python-pip_20.0.2-5_20.0.2-5ubuntu1.diff.gz

As you can see, python-wheel is no longer available, and some of the
other libraries dirtbike uses are probably heading that way.

So, to make that approach work, we have to introduce more py2-only
libraries again, or allow dirtbike to build py2 wheels while running
under python3.

> It still needs the Python policy change since they aren't universal, but it 
> would allow setuptools to keep up for python3 in pip without dropping the 
> local wheels from python2.  We also have ipaddr back in the archive to support 
> wheeling it so pip will run with python2.

But, without the py2 setuptools wheels, I don't know much that buys us.

Long-term: pypy (2.7) is going to continue to be around, until rpython
moves to python3 (which is still officially never, but people are
starting to poke at it).
https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-python2

If we have a python 2 interpreter, it's really nice to have working
virtualenv for it. Makes it a lot more useful for users, esp. as we
don't have many debian libraries packaged for it.

So, the options are:
1. pin pip dependencies at versions that support py2, forever. Obviously
   this is a no-go.
2. Ship py2 and py3 wheels.
   2.1. package the py2 weels with dirtbike. This requires bringing back
        python-wheel, or more work on dirtbike.
   2.2. Ship static py2 wheels (like we did pre-dirtbike). It's not like
        upstream is continuing development...
3. Let virtualenv always download pip from pypi for py2. Only ship py3
   wheels.

The easy options here are 2.2 and 3.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

[toc] | [prev] | [next] | [standalone]

#12544

[Multipart message — attachments visible in raw view] — view raw

On Thursday, April 30, 2020 2:32:24 PM EDT Stefano Rivera wrote:
> Hi Scott (2020.04.30_16:23:41_+0000)
> 
> > Making dirtbike build a py3 wheel for setuptools (and pkg_resources),
> > which is technically accurate at this point since dirtbike can't build
> > wheels from a> 
> > python2 package was trivial to do:
> >  dirtbike/__init__.py | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > Three of the five insertions were comment.
> 
> That seems reasonable, although if we're going down that road, it
> probably makes no sense for any of them to be universal.

If we were talking about maintaining this for multiple release cycles with 
lots of version divergence, I would agree.  Let's not do more than we have to 
until python2 is gone (whether it is before bullseye or after).

> > If someone wants to provide a patch to dirtbike so it can also build
> > wheels
> > from python-setuptools and python-pkg-resources, then we could add then to
> > build-depends and provide both a set of py2 wheels and py3 wheels for as
> > long as they are in the archive.
> 
> The window for doing this is probably closing, too.
> 
> I hacked this in Ubuntu 20.04, just before release:
> https://launchpadlibrarian.net/475592029/python-pip_20.0.2-5_20.0.2-5ubuntu1
> .diff.gz
> 
> As you can see, python-wheel is no longer available, and some of the
> other libraries dirtbike uses are probably heading that way.
> 
> So, to make that approach work, we have to introduce more py2-only
> libraries again, or allow dirtbike to build py2 wheels while running
> under python3.

I had in mind the latter.  I looked and there's not a lot of difference in the 
metadata of a pure python wheel that's universal and one that's not.  The 
universal one has tags for both versions:

$ cat WHEEL 
Wheel-Version: 1.0
Generator: bdist_wheel (0.34.2)
Root-Is-Purelib: true
Tag: py2-none-any
Tag: py3-none-any

As a result, one could add some kind of py2 flag to dirtbike to tell it to look 
in /usr/lib/python2.7/dist-packages and make a 'universal' wheel from there.  
It could then rename the files from py2.py3-none-any.whl to py2-none-any.whl.  
The bonus Tag in the WHEEL file shouldn't hurt anything.

They key is I think we can do this without actually running python2, we just 
need to be able to install python-setuptools/pkg-resources.  That should be 
supportable ~as long as python2.7 is in the archive.

> > It still needs the Python policy change since they aren't universal, but
> > it
> > would allow setuptools to keep up for python3 in pip without dropping the
> > local wheels from python2.  We also have ipaddr back in the archive to
> > support wheeling it so pip will run with python2.
> 
> But, without the py2 setuptools wheels, I don't know much that buys us.

Technically I think it's solvable and is supportable until the python2 
interpreter goes away.

> Long-term: pypy (2.7) is going to continue to be around, until rpython
> moves to python3 (which is still officially never, but people are
> starting to poke at it).
> https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-python2
> 
> If we have a python 2 interpreter, it's really nice to have working
> virtualenv for it. Makes it a lot more useful for users, esp. as we
> don't have many debian libraries packaged for it.

Agreed.  As long as pip supports python2, we should try.  Worst case we can 
tell people to find their own interpreter and do a --download install with 
setuptools pinned to 44.0.0 (that approach doesn't need ipaddr because they'll 
get the upstream pip in the virtualenv too.  

> So, the options are:
> 1. pin pip dependencies at versions that support py2, forever. Obviously
>    this is a no-go.
> 2. Ship py2 and py3 wheels.
>    2.1. package the py2 weels with dirtbike. This requires bringing back
>         python-wheel, or more work on dirtbike.
>    2.2. Ship static py2 wheels (like we did pre-dirtbike). It's not like
>         upstream is continuing development...
> 3. Let virtualenv always download pip from pypi for py2. Only ship py3
>    wheels.
> 
> The easy options here are 2.2 and 3.

2.1a Where needed package 'py2' wheels with dirtbike running python3.

2.2 is using sourceless binaries, so I think it's got DFSG issues.  We need 
the preferred form of modification and a bdist_wheel is not that.

I think 2.1a would be nice if someone can manage it.  We'll need to support 3 
eventually.  I plan to implement 3 as an option when I upload pip 20.1 and 
virtualenv 2.0.18.

Scott K

[toc] | [prev] | [next] | [standalone]

#12546

Hi Scott (2020.04.30_20:33:59_+0000)
> > That seems reasonable, although if we're going down that road, it
> > probably makes no sense for any of them to be universal.
> 
> If we were talking about maintaining this for multiple release cycles with 
> lots of version divergence, I would agree.  Let's not do more than we have to 
> until python2 is gone (whether it is before bullseye or after).

I suspect pypy (2.7) will probably be around post-bullseye, unless
somebody funds pypy to migrate rpython to python 3.

But yeah, we can change strategy later, if appropriate.

> As a result, one could add some kind of py2 flag to dirtbike to tell it to look 
> in /usr/lib/python2.7/dist-packages and make a 'universal' wheel from there.  
> It could then rename the files from py2.py3-none-any.whl to py2-none-any.whl.  
> The bonus Tag in the WHEEL file shouldn't hurt anything.
>
> They key is I think we can do this without actually running python2, we just 
> need to be able to install python-setuptools/pkg-resources.  That should be 
> supportable ~as long as python2.7 is in the archive.

Yep, that sounds good.

> Agreed.  As long as pip supports python2, we should try.  Worst case we can 
> tell people to find their own interpreter and do a --download install with 
> setuptools pinned to 44.0.0 (that approach doesn't need ipaddr because they'll 
> get the upstream pip in the virtualenv too.  

When we get to the download route: pip can parse Requires-Python, and it
looks like virtualenv uses the system pip to download pip, so the
pinning shouldn't be necessary, I think.

> > So, the options are:
> > 1. pin pip dependencies at versions that support py2, forever. Obviously
> >    this is a no-go.
> > 2. Ship py2 and py3 wheels.
> >    2.1. package the py2 weels with dirtbike. This requires bringing back
> >         python-wheel, or more work on dirtbike.
> >    2.2. Ship static py2 wheels (like we did pre-dirtbike). It's not like
> >         upstream is continuing development...
> > 3. Let virtualenv always download pip from pypi for py2. Only ship py3
> >    wheels.
> > 
> > The easy options here are 2.2 and 3.
> 
> 2.1a Where needed package 'py2' wheels with dirtbike running python3.

Ah, yeah.

Still requires keeping py2 source packages whenever a library in the pip
dependency stack drops py2 support. But if they move slowly, that's
fine.

> 2.2 is using sourceless binaries, so I think it's got DFSG issues.  We need 
> the preferred form of modification and a bdist_wheel is not that.

They could be bdist_wheeled at build time, within a single source
package.

> I think 2.1a would be nice if someone can manage it.  We'll need to support 3 
> eventually.  I plan to implement 3 as an option when I upload pip 20.1 and 
> virtualenv 2.0.18.

Not necessarily. 2.2 is equivalent to 3, but without hitting PyPI.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

[toc] | [prev] | [next] | [standalone]

#12547

[Multipart message — attachments visible in raw view] — view raw

On Thursday, April 30, 2020 5:49:20 PM EDT Stefano Rivera wrote:
> Hi Scott (2020.04.30_20:33:59_+0000)
> 
> > > That seems reasonable, although if we're going down that road, it
> > > probably makes no sense for any of them to be universal.
> > 
> > If we were talking about maintaining this for multiple release cycles with
> > lots of version divergence, I would agree.  Let's not do more than we have
> > to until python2 is gone (whether it is before bullseye or after).
> 
> I suspect pypy (2.7) will probably be around post-bullseye, unless
> somebody funds pypy to migrate rpython to python 3.
> 
> But yeah, we can change strategy later, if appropriate.

Well, we have also talked about pypy vendoring as much of the python2.7 
package as it needs to build itself so we don't have to support it in the 
archive as an active interpreter, but that's a different discussion.

> > As a result, one could add some kind of py2 flag to dirtbike to tell it to
> > look in /usr/lib/python2.7/dist-packages and make a 'universal' wheel
> > from there. It could then rename the files from py2.py3-none-any.whl to
> > py2-none-any.whl. The bonus Tag in the WHEEL file shouldn't hurt
> > anything.
> > 
> > They key is I think we can do this without actually running python2, we
> > just need to be able to install python-setuptools/pkg-resources.  That
> > should be supportable ~as long as python2.7 is in the archive.
> 
> Yep, that sounds good.
> 
> > Agreed.  As long as pip supports python2, we should try.  Worst case we
> > can
> > tell people to find their own interpreter and do a --download install with
> > setuptools pinned to 44.0.0 (that approach doesn't need ipaddr because
> > they'll get the upstream pip in the virtualenv too.
> 
> When we get to the download route: pip can parse Requires-Python, and it
> looks like virtualenv uses the system pip to download pip, so the
> pinning shouldn't be necessary, I think.

I haven't really tested that yet, so I don't doubt that.  It was an 
assumption.  My first run at virtualenv ran aground on trying to have different 
package lists depending on if the install invoked --download or not (since a 
--download install with the upstream pip doesn't need all the unvendored 
wheels).  So that's something to sort later.  We'll want to document how to do 
it even if we get a working solution that doesn't require it.

> > > So, the options are:
> > > 1. pin pip dependencies at versions that support py2, forever. Obviously
> > > 
> > >    this is a no-go.
> > > 
> > > 2. Ship py2 and py3 wheels.
> > > 
> > >    2.1. package the py2 weels with dirtbike. This requires bringing back
> > >    
> > >         python-wheel, or more work on dirtbike.
> > >    
> > >    2.2. Ship static py2 wheels (like we did pre-dirtbike). It's not like
> > >    
> > >         upstream is continuing development...
> > > 
> > > 3. Let virtualenv always download pip from pypi for py2. Only ship py3
> > > 
> > >    wheels.
> > > 
> > > The easy options here are 2.2 and 3.
> > 
> > 2.1a Where needed package 'py2' wheels with dirtbike running python3.
> 
> Ah, yeah.
> 
> Still requires keeping py2 source packages whenever a library in the pip
> dependency stack drops py2 support. But if they move slowly, that's
> fine.

So far setuptools is the only one.  It might pick up though now that they've 
done it.  We've split packages into a source for python2 and a source for 
python3 in a number of cases, so I think this scales reasonably.  We can just 
yank all the python2 sources the same time pip drops python2 or we do.

> > 2.2 is using sourceless binaries, so I think it's got DFSG issues.  We
> > need
> > the preferred form of modification and a bdist_wheel is not that.
> 
> They could be bdist_wheeled at build time, within a single source
> package.
> 
> > I think 2.1a would be nice if someone can manage it.  We'll need to
> > support 3 eventually.  I plan to implement 3 as an option when I upload
> > pip 20.1 and virtualenv 2.0.18.
> 
> Not necessarily. 2.2 is equivalent to 3, but without hitting PyPI.

Let's focus on 2.1a so we don't have to have that argument ...

I might actually have a little time tomorrow to work on it.

Scott K

[toc] | [prev] | [next] | [standalone]

#12548

[Multipart message — attachments visible in raw view] — view raw

On Thursday, April 30, 2020 6:21:48 PM EDT Scott Kitterman wrote:
> On Thursday, April 30, 2020 5:49:20 PM EDT Stefano Rivera wrote:
> > Hi Scott (2020.04.30_20:33:59_+0000)
> > 
> > > > That seems reasonable, although if we're going down that road, it
> > > > probably makes no sense for any of them to be universal.
> > > 
> > > If we were talking about maintaining this for multiple release cycles
> > > with
> > > lots of version divergence, I would agree.  Let's not do more than we
> > > have
> > > to until python2 is gone (whether it is before bullseye or after).
> > 
> > I suspect pypy (2.7) will probably be around post-bullseye, unless
> > somebody funds pypy to migrate rpython to python 3.
> > 
> > But yeah, we can change strategy later, if appropriate.
> 
> Well, we have also talked about pypy vendoring as much of the python2.7
> package as it needs to build itself so we don't have to support it in the
> archive as an active interpreter, but that's a different discussion.
> 
> > > As a result, one could add some kind of py2 flag to dirtbike to tell it
> > > to
> > > look in /usr/lib/python2.7/dist-packages and make a 'universal' wheel
> > > from there. It could then rename the files from py2.py3-none-any.whl to
> > > py2-none-any.whl. The bonus Tag in the WHEEL file shouldn't hurt
> > > anything.
> > > 
> > > They key is I think we can do this without actually running python2, we
> > > just need to be able to install python-setuptools/pkg-resources.  That
> > > should be supportable ~as long as python2.7 is in the archive.
> > 
> > Yep, that sounds good.
> > 
> > > Agreed.  As long as pip supports python2, we should try.  Worst case we
> > > can
> > > tell people to find their own interpreter and do a --download install
> > > with
> > > setuptools pinned to 44.0.0 (that approach doesn't need ipaddr because
> > > they'll get the upstream pip in the virtualenv too.
> > 
> > When we get to the download route: pip can parse Requires-Python, and it
> > looks like virtualenv uses the system pip to download pip, so the
> > pinning shouldn't be necessary, I think.
> 
> I haven't really tested that yet, so I don't doubt that.  It was an
> assumption.  My first run at virtualenv ran aground on trying to have
> different package lists depending on if the install invoked --download or
> not (since a --download install with the upstream pip doesn't need all the
> unvendored wheels).  So that's something to sort later.  We'll want to
> document how to do it even if we get a working solution that doesn't
> require it.
> 
> > > > So, the options are:
> > > > 1. pin pip dependencies at versions that support py2, forever.
> > > > Obviously
> > > > 
> > > >    this is a no-go.
> > > > 
> > > > 2. Ship py2 and py3 wheels.
> > > > 
> > > >    2.1. package the py2 weels with dirtbike. This requires bringing
> > > >    back
> > > >    
> > > >         python-wheel, or more work on dirtbike.
> > > >    
> > > >    2.2. Ship static py2 wheels (like we did pre-dirtbike). It's not
> > > >    like
> > > >    
> > > >         upstream is continuing development...
> > > > 
> > > > 3. Let virtualenv always download pip from pypi for py2. Only ship py3
> > > > 
> > > >    wheels.
> > > > 
> > > > The easy options here are 2.2 and 3.
> > > 
> > > 2.1a Where needed package 'py2' wheels with dirtbike running python3.
> > 
> > Ah, yeah.
> > 
> > Still requires keeping py2 source packages whenever a library in the pip
> > dependency stack drops py2 support. But if they move slowly, that's
> > fine.
> 
> So far setuptools is the only one.  It might pick up though now that they've
> done it.  We've split packages into a source for python2 and a source for
> python3 in a number of cases, so I think this scales reasonably.  We can
> just yank all the python2 sources the same time pip drops python2 or we do.
> > > 2.2 is using sourceless binaries, so I think it's got DFSG issues.  We
> > > need
> > > the preferred form of modification and a bdist_wheel is not that.
> > 
> > They could be bdist_wheeled at build time, within a single source
> > package.
> > 
> > > I think 2.1a would be nice if someone can manage it.  We'll need to
> > > support 3 eventually.  I plan to implement 3 as an option when I upload
> > > pip 20.1 and virtualenv 2.0.18.
> > 
> > Not necessarily. 2.2 is equivalent to 3, but without hitting PyPI.
> 
> Let's focus on 2.1a so we don't have to have that argument ...
> 
> I might actually have a little time tomorrow to work on it.

This is done and in PAPT git for dirtbike.  Improvements welcome.  It works, 
but isn't pretty in some cases.

For now, we can provide a universal wheel for setuptools and pkg_resources 
from the python-* variant packages, so a policy change isn't urgent.

Given the method dirtbike is going to use, it would be trivial to have py3 
only wheels for them as well.  I think that is preferable since it would allow 
python3 users the benefits of the newer releases, so I still think the policy 
change is a good idea, but since it is less urgent than when I originally 
wrote, I'm not pushing for a new upload of the policy.

Scott K

[toc] | [prev] | [next] | [standalone]

#12549

[Multipart message — attachments visible in raw view] — view raw

Hi,

Scott Kitterman <debian@kitterman.com> writes:

> On Thursday, April 30, 2020 5:49:20 PM EDT Stefano Rivera wrote:
>> Hi Scott (2020.04.30_20:33:59_+0000)
>> 
>> > > That seems reasonable, although if we're going down that road, it
>> > > probably makes no sense for any of them to be universal.
>> > 
>> > If we were talking about maintaining this for multiple release cycles with
>> > lots of version divergence, I would agree.  Let's not do more than we have
>> > to until python2 is gone (whether it is before bullseye or after).
>> 
>> I suspect pypy (2.7) will probably be around post-bullseye, unless
>> somebody funds pypy to migrate rpython to python 3.
>> 
>> But yeah, we can change strategy later, if appropriate.
>
> Well, we have also talked about pypy vendoring as much of the python2.7 
> package as it needs to build itself so we don't have to support it in the 
> archive as an active interpreter, but that's a different discussion.
>

I think that discussion must have been before I joined the team :-) It's
only recently that I became aware of pypy, and I assumed it had been
discounted because it weakened the argument (and/or was bad for morale)
for the py2 removal initiative we saw in 2019.

I can't remember if it was on reddit or stackoverflow, but apparently
people are considering pypy 2.7 as a solution to their py2 technical
debt.

It makes sense that a vendoring/bootstrapping/dfsg-compliance issue was
the reason the avenue wasn't explored in Debian, and I'm happy to hear
that this was the reason pypy wasn't explored as an alternative--and not
my assumption.

Thanks,
Nicholas

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web