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

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

Python 2 removal strategy

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

Contents

  Python 2 removal strategy Ole Streicher <olebole@debian.org> - 2018-01-10 17:30 +0100
    Re: Python 2 removal strategy Matthias Klose <doko@debian.org> - 2018-01-10 22:10 +0100
      Re: Python 2 removal strategy "eamanu15 ." <emmanuelarias30@gmail.com> - 2018-01-10 23:30 +0100
    Re: Python 2 removal strategy Stuart Prescott <stuart@debian.org> - 2018-01-11 01:20 +0100

#10031 — Python 2 removal strategy

Hi,

I am the maintainer of the "python-astropy" package, that currently
creates packages for both Python 2 and Python 3. Both packages have a
number of reverse dependencies.

Recently, upstream announced a new version 3.0 of astropy, which
supports Python 3 only, and I think of the best mid-term strategy: The
old version 2.0 is supported upstream for ~2 years, and I want to have a
smooth migration path. I checked the wiki, but could not find good
information about migration.

I thought of a temporary package split: create a new source package
"astropy" that inherits of the current python-astropy package, but only
builds python3-astropy (and the utils + doc, which depend on
python3-astropy), and update this to version 3.0. Then I would remove
these binary packages from the python-astropy package. In parallel, I
would file bugs (severity: important) to remove the reverse dependencies
of the Python 2 packages (many of them are mine, but also may have
reverse dependencies).

As long as there are substantial problems with the removal of the Python
2 support, I then keep the "old" python-astropy package updated. Once
everything is figured out and we decide to finally kick out Python 2
support (from Debian-Astro, or from Debian), I would set the remaining
bugs as RC, and (once they are solved) remove the "python-astropy"
package.

Does this sound reasonable? And how should I do this technically?

Best regards

Ole

[toc] | [next] | [standalone]

#10033

On 10.01.2018 17:06, Ole Streicher wrote:
> Hi,
> 
> I am the maintainer of the "python-astropy" package, that currently
> creates packages for both Python 2 and Python 3. Both packages have a
> number of reverse dependencies.
> 
> Recently, upstream announced a new version 3.0 of astropy, which
> supports Python 3 only, and I think of the best mid-term strategy: The
> old version 2.0 is supported upstream for ~2 years, and I want to have a
> smooth migration path. I checked the wiki, but could not find good
> information about migration.

Currently discussed. See "Python2 EOL and moving towards Python3" on this ML.

> I thought of a temporary package split: create a new source package
> "astropy" that inherits of the current python-astropy package, but only
> builds python3-astropy (and the utils + doc, which depend on
> python3-astropy), and update this to version 3.0. Then I would remove
> these binary packages from the python-astropy package. In parallel, I
> would file bugs (severity: important) to remove the reverse dependencies
> of the Python 2 packages (many of them are mine, but also may have
> reverse dependencies).
> 
> As long as there are substantial problems with the removal of the Python
> 2 support, I then keep the "old" python-astropy package updated. Once
> everything is figured out and we decide to finally kick out Python 2
> support (from Debian-Astro, or from Debian), I would set the remaining
> bugs as RC, and (once they are solved) remove the "python-astropy"
> package.
> 
> Does this sound reasonable? And how should I do this technically?

well, astropy is not such a mainstream package that I would mind removing some
of it's reverse dependencies.  If you want to add the additional pain having a
separate Python2 source stack, go for it. I wouldn't want to do that myself.  If
not, just go ahead with Python3 after having identified the reverse dependencies
which are not maintained by yourself.

Matthias

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

#10034

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

Hi Ole,

It would be great have two different package. One of them, the python3
version and maintain the python2 version.

Regards!
Emmanuel

El mié., 10 de ene. de 2018 a la(s) 18:03, Matthias Klose <doko@debian.org>
escribió:

> On 10.01.2018 17:06, Ole Streicher wrote:
> > Hi,
> >
> > I am the maintainer of the "python-astropy" package, that currently
> > creates packages for both Python 2 and Python 3. Both packages have a
> > number of reverse dependencies.
> >
> > Recently, upstream announced a new version 3.0 of astropy, which
> > supports Python 3 only, and I think of the best mid-term strategy: The
> > old version 2.0 is supported upstream for ~2 years, and I want to have a
> > smooth migration path. I checked the wiki, but could not find good
> > information about migration.
>
> Currently discussed. See "Python2 EOL and moving towards Python3" on this
> ML.
>
> > I thought of a temporary package split: create a new source package
> > "astropy" that inherits of the current python-astropy package, but only
> > builds python3-astropy (and the utils + doc, which depend on
> > python3-astropy), and update this to version 3.0. Then I would remove
> > these binary packages from the python-astropy package. In parallel, I
> > would file bugs (severity: important) to remove the reverse dependencies
> > of the Python 2 packages (many of them are mine, but also may have
> > reverse dependencies).
> >
> > As long as there are substantial problems with the removal of the Python
> > 2 support, I then keep the "old" python-astropy package updated. Once
> > everything is figured out and we decide to finally kick out Python 2
> > support (from Debian-Astro, or from Debian), I would set the remaining
> > bugs as RC, and (once they are solved) remove the "python-astropy"
> > package.
> >
> > Does this sound reasonable? And how should I do this technically?
>
> well, astropy is not such a mainstream package that I would mind removing
> some
> of it's reverse dependencies.  If you want to add the additional pain
> having a
> separate Python2 source stack, go for it. I wouldn't want to do that
> myself.  If
> not, just go ahead with Python3 after having identified the reverse
> dependencies
> which are not maintained by yourself.
>
> Matthias
>
>

-- 
Arias Emmanuel
https://www.linkedin.com/in/emmanuel-arias-437a6a8a
http://eamanu.com

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

#10035

Hi Ole,

> I thought of a temporary package split: create a new source package
> "astropy" that inherits of the current python-astropy package, but only
> builds python3-astropy (and the utils + doc, which depend on
> python3-astropy), and update this to version 3.0. Then I would remove
> these binary packages from the python-astropy package. In parallel, I
> would file bugs (severity: important) to remove the reverse dependencies
> of the Python 2 packages (many of them are mine, but also may have
> reverse dependencies).

This is more or less what I ended up doing for the plotting module PyX and I 
think it's a reasonable path forward given that there will also be lots of 
legacy user scripts out there that are using pyx (and astropy) that don't 
need to be broken just yet.

The pyx source continues to build python-pyx and is stuck at the last 
version of pyx that supported Python 2. It's only used by users in their 
existing scripts for plotting their data and they will keep working for as 
long as we have a Python 2 interpreter. The only changes that happen in 
python-pyx are adjusting to new dependencies such as python-imaging → 
python-pil.

An additional source package pyx3 builds python3-pyx and is tracking 
upstream releases meaning new features get added etc. pyx3 isn't a great 
source name but then users never see it and certainly never need to guess 
it. That said, pyx3 is probably less confusing as a name than astropy vs 
python-astropy.

I've wondered about putting some noisy warnings into the python-pyx code 
that talks about the need to migrate to Python 3 if you want your scripts to 
keep working into the future. I've not done so because I assume that anyone 
using pyx probably pays attention to upstream documentation and knows this 
story already; at the risk of hijacking this thread, I'd be interested in 
the thoughts of others on this.

cheers
Stuart


-- 
Stuart Prescott    http://www.nanonanonano.net/   stuart@nanonanonano.net
Debian Developer   http://www.debian.org/         stuart@debian.org
GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

[toc] | [prev] | [standalone]

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

csiph-web