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

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

Matplotlib 3.0 - update ok?

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

Contents

  Matplotlib 3.0 - update ok? Steffen Möller <steffen.moeller@uni-rostock.de> - 2018-10-15 23:10 +0200
    Re: Matplotlib 3.0 - update ok? ghisvail@gmail.com - 2018-10-16 08:40 +0200
      Re: Matplotlib 3.0 - update ok? Andreas Tille <andreas@an3as.eu> - 2018-10-16 08:50 +0200
        Re: Matplotlib 3.0 - update ok? ghisvail@gmail.com - 2018-10-16 09:00 +0200
          Re: Matplotlib 3.0 - update ok? Andreas Tille <andreas@an3as.eu> - 2018-10-16 09:10 +0200
            Re: Matplotlib 3.0 - update ok? ghisvail@gmail.com - 2018-10-16 09:20 +0200
              Re: Matplotlib 3.0 - update ok? Ole Streicher <olebole@debian.org> - 2018-10-16 10:00 +0200
                Re: Matplotlib 3.0 - update ok? ghisvail@gmail.com - 2018-10-16 10:30 +0200
                  Re: Matplotlib 3.0 - update ok? Arto Jantunen <viiru@debian.org> - 2018-10-16 11:00 +0200
                    Re: Matplotlib 3.0 - update ok? ghisvail@gmail.com - 2018-10-16 11:20 +0200
                      Re: Matplotlib 3.0 - update ok? Arto Jantunen <viiru@debian.org> - 2018-10-16 11:30 +0200
                      Re: Matplotlib 3.0 - update ok? Michael Hudson-Doyle <michael.hudson@canonical.com> - 2018-10-16 12:10 +0200
      Re: Matplotlib 3.0 - update ok? Steffen Möller <steffen.moeller@uni-rostock.de> - 2018-10-16 10:40 +0200
        Re: Matplotlib 3.0 - update ok? ghisvail@gmail.com - 2018-10-16 10:50 +0200
        Re: Matplotlib 3.0 - update ok? Steffen Möller <steffen_moeller@gmx.de> - 2018-10-16 10:50 +0200
          Re: Matplotlib 3.0 - update ok? ghisvail@gmail.com - 2018-10-16 11:10 +0200
    Re: Matplotlib 3.0 - update ok? "W. Martin Borgert" <debacle@debian.org> - 2018-10-16 14:00 +0200
    Re: Matplotlib 3.0 - update ok? Sandro Tosi <morph@debian.org> - 2018-10-16 14:40 +0200

#11010 — Matplotlib 3.0 - update ok?

Hello,

I am keeping me busy packaging the Orange machine learning library that 
seems nice (https://orange.biolab.si/#Orange-Features). Now, the test 
routines demand a matplotlib.pyplot module that is not in version 2 that 
we feature. Version 3 is the current stable release.

Now, I am tempted to create a package matplotlib3 instead of forcing 
everyone to update from this long term release (see 
https://matplotlib.org/).

Any opinions from your sides?

Cheers,

Steffen

[toc] | [next] | [standalone]

#11011

On Mon, 2018-10-15 at 22:44 +0200, Steffen Möller wrote:
> Hello,
> 
> I am keeping me busy packaging the Orange machine learning library
> that 
> seems nice (https://orange.biolab.si/#Orange-Features). Now, the
> test 
> routines demand a matplotlib.pyplot module that is not in version 2
> that 
> we feature. Version 3 is the current stable release.

Ack. Thank you for explaining the context.

> Now, I am tempted to create a package matplotlib3 instead of forcing 
> everyone to update from this long term release (see 
> https://matplotlib.org/).
> 
> Any opinions from your sides?

How is that going to work without creating package conflicts?

I suppose  the main module is still named "matplotlib" not
"matplotlib3" in version 3 onwards? So using python3-matplotlib3 would
be a breach of policy.

Let me ask you this: where is the rush to package this machine learning
library? Could it wait after the Buster release cycle, where we might
be in a more comfortable position to upgrade matplotlib?

Cheers,
Ghis

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

#11012

On Tue, Oct 16, 2018 at 07:30:55AM +0100, ghisvail@gmail.com wrote:
> > Any opinions from your sides?
> 
> How is that going to work without creating package conflicts?
> 
> I suppose  the main module is still named "matplotlib" not
> "matplotlib3" in version 3 onwards? So using python3-matplotlib3 would
> be a breach of policy.

Probably.
 
> Let me ask you this: where is the rush to package this machine learning
> library? Could it wait after the Buster release cycle, where we might
> be in a more comfortable position to upgrade matplotlib?

I'm not sure what might be the difference between:

   3.0.0 Stable version
   2.2.3 LTS LTS version

We have some months left until freeze so may be right now it is not to
late to package what upstream considers stable.

Kind regards

      Andreas.

-- 
http://fam-tille.de

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

#11013

On Tue, 2018-10-16 at 08:46 +0200, Andreas Tille wrote:
> On Tue, Oct 16, 2018 at 07:30:55AM +0100, ghisvail@gmail.com wrote:
> > > Any opinions from your sides?
> > 
> > How is that going to work without creating package conflicts?
> > 
> > I suppose  the main module is still named "matplotlib" not
> > "matplotlib3" in version 3 onwards? So using python3-matplotlib3
> > would
> > be a breach of policy.
> 
> Probably.

Described in Section 2.2 of the Debian Python policy.

> > Let me ask you this: where is the rush to package this machine
> > learning
> > library? Could it wait after the Buster release cycle, where we
> > might
> > be in a more comfortable position to upgrade matplotlib?
> 
> I'm not sure what might be the difference between:
> 
>    3.0.0 Stable version
>    2.2.3 LTS LTS version
> 
> We have some months left until freeze so may be right now it is not
> to
> late to package what upstream considers stable.
> 
> Kind regards
> 
>       Andreas.


>From the upstream homepage: "Matplotlib 3.0 is Python 3 only."

Afaik, Python 2 is still considered relevant for the Buster release
cycle. Hence why I am suggesting to wait for the next release cycle
before upgrading key scientific packages, such as matplotlib, to Python
3 only.

Cheers,
Ghis

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

#11015

On Tue, Oct 16, 2018 at 07:55:40AM +0100, ghisvail@gmail.com wrote:
> > > I suppose  the main module is still named "matplotlib" not
> > > "matplotlib3" in version 3 onwards? So using python3-matplotlib3
> > > would
> > > be a breach of policy.
> > 
> > Probably.
> 
> Described in Section 2.2 of the Debian Python policy.

Depending how heavy Steffen would volunteer to patch and also rename the
module (which I would not consider a very sensible idea).
 
> > I'm not sure what might be the difference between:
> > 
> >    3.0.0 Stable version
> >    2.2.3 LTS LTS version
> > 
> > We have some months left until freeze so may be right now it is not
> > to
> > late to package what upstream considers stable.
> > 
> > Kind regards
> > 
> >       Andreas.
> 
> 
> >From the upstream homepage: "Matplotlib 3.0 is Python 3 only."
> 
> Afaik, Python 2 is still considered relevant for the Buster release
> cycle. Hence why I am suggesting to wait for the next release cycle
> before upgrading key scientific packages, such as matplotlib, to Python
> 3 only.

Right.  This would surely kick several scientific packages.

Kind regards

      Andreas. 

-- 
http://fam-tille.de

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

#11016

On Tue, 2018-10-16 at 09:00 +0200, Andreas Tille wrote:
> On Tue, Oct 16, 2018 at 07:55:40AM +0100, ghisvail@gmail.com wrote:
> > > > I suppose  the main module is still named "matplotlib" not
> > > > "matplotlib3" in version 3 onwards? So using python3-
> > > > matplotlib3
> > > > would
> > > > be a breach of policy.
> > > 
> > > Probably.
> > 
> > Described in Section 2.2 of the Debian Python policy.
> 
> Depending how heavy Steffen would volunteer to patch and also rename
> the
> module (which I would not consider a very sensible idea).

Which means future packages depending on matplotlib v3+ would have to
be manually patched to account for the renaming. Sounds impractical to
me.

> > > I'm not sure what might be the difference between:
> > > 
> > >    3.0.0 Stable version
> > >    2.2.3 LTS LTS version
> > > 
> > > We have some months left until freeze so may be right now it is
> > > not
> > > to
> > > late to package what upstream considers stable.
> > > 
> > > Kind regards
> > > 
> > >       Andreas.
> > > From the upstream homepage: "Matplotlib 3.0 is Python 3 only."
> > 
> > Afaik, Python 2 is still considered relevant for the Buster release
> > cycle. Hence why I am suggesting to wait for the next release cycle
> > before upgrading key scientific packages, such as matplotlib, to
> > Python
> > 3 only.
> 
> Right.  This would surely kick several scientific packages.
> 
> Kind regards
> 
>       Andreas. 

Indeed. Note that NumPy has already published plans to become Python 3
only in the near future, so the deprecation of Python 2 in the
scientific stack will happen eventually.

I just don't think it should be rushed into the Buster release cycle.

Ghis

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

#11017

ghisvail@gmail.com writes:
> Indeed. Note that NumPy has already published plans to become Python 3
> only in the near future, so the deprecation of Python 2 in the
> scientific stack will happen eventually.
>
> I just don't think it should be rushed into the Buster release cycle.

If we really want to then have a Python-2-numpy, why can't there be a
separate Python-2 legacy numpy source package? I do the same for
astropy.

Holding back normal updates especially for science packages just because
we don't want to use a modern numpy/scipy/matplotlib stack is not really
friendly to our users, which (in science) rely on at least "somehow"
modern software. And astropy that is more than a 1.5 years old already
at the release of Buster would not be accepted by the users, and
patching it to use an older sw stack is also impractical.

Even when we /still/ support Python 2, our focus and preference should
be clearly Python 3.

Best regards

Ole

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

#11018

On Tue, 2018-10-16 at 09:38 +0200, Ole Streicher wrote:
> ghisvail@gmail.com writes:
> > Indeed. Note that NumPy has already published plans to become
> > Python 3
> > only in the near future, so the deprecation of Python 2 in the
> > scientific stack will happen eventually.
> > 
> > I just don't think it should be rushed into the Buster release
> > cycle.
> 
> If we really want to then have a Python-2-numpy, why can't there be a
> separate Python-2 legacy numpy source package? I do the same for
> astropy.

Who is "we"? I never said that personally.

> Holding back normal updates especially for science packages just
> because
> we don't want to use a modern numpy/scipy/matplotlib stack is not
> really
> friendly to our users, which (in science) rely on at least "somehow"
> modern software. And astropy that is more than a 1.5 years old
> already
> at the release of Buster would not be accepted by the users, and
> patching it to use an older sw stack is also impractical.

Afaik, matplotlib v2.x is under an LTS release scheme, so I don't think
we are holding anything back. Same rationales for IPython, for which we
maintain packages for the v5.x LTS releases instead of tracking v6.x.

> 
> Even when we /still/ support Python 2, our focus and preference
> should
> be clearly Python 3.

Don't get me wrong, I am all in favour for a modern stack, including
Python 3.

However, upgrading NumPy et al. to their Python 3 only versions,
introducing new legacy packages for Python 2, and patching the large
collection of packages relying on the Python 2 versions of these sounds
like a lot of work for the time we have got left in the Buster release
cycle.

Let me ask you this: besides Steffen's ITP, is there anything urgently
calling for an upgrade of the scientific stack to something newer than
the LTS versions? Where urgently implies fixing RC bugs impeding the
Buster release. Maybe there are. If not, where is the rush really?

Ghis

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

#11022

ghisvail@gmail.com writes:
> Don't get me wrong, I am all in favour for a modern stack, including
> Python 3.
>
> However, upgrading NumPy et al. to their Python 3 only versions,
> introducing new legacy packages for Python 2, and patching the large
> collection of packages relying on the Python 2 versions of these sounds
> like a lot of work for the time we have got left in the Buster release
> cycle.

In my understanding there is no need to patch any of the reverse
dependencies. Currently there are binary packages called python-numpy
and python3-numpy, built from a source package called python-numpy. In
my understanding the proposed change is to keep having the exact same
binary packages, just built from two different source packages
(python-numpy and python-numpy-legacy or whatever).

-- 
Arto Jantunen

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

#11024

On Tue, 2018-10-16 at 11:45 +0300, Arto Jantunen wrote:
> ghisvail@gmail.com writes:
> > Don't get me wrong, I am all in favour for a modern stack,
> > including
> > Python 3.
> > 
> > However, upgrading NumPy et al. to their Python 3 only versions,
> > introducing new legacy packages for Python 2, and patching the
> > large
> > collection of packages relying on the Python 2 versions of these
> > sounds
> > like a lot of work for the time we have got left in the Buster
> > release
> > cycle.
> 
> In my understanding there is no need to patch any of the reverse
> dependencies. Currently there are binary packages called python-numpy
> and python3-numpy, built from a source package called python-numpy.
> In
> my understanding the proposed change is to keep having the exact same
> binary packages, just built from two different source packages
> (python-numpy and python-numpy-legacy or whatever).

Oh, I see what you mean.

So you'd have:

- src:python-numpy-legacy providing python-numpy (<2.0) only
- src:python-numpy providing python3-numpy (>=2.0) only

Assuming version 2 is when the split happens.

Am I correct?

Ghis

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

#11025

ghisvail@gmail.com writes:

> On Tue, 2018-10-16 at 11:45 +0300, Arto Jantunen wrote:
>> ghisvail@gmail.com writes:
>> > Don't get me wrong, I am all in favour for a modern stack,
>> > including
>> > Python 3.
>> > 
>> > However, upgrading NumPy et al. to their Python 3 only versions,
>> > introducing new legacy packages for Python 2, and patching the
>> > large
>> > collection of packages relying on the Python 2 versions of these
>> > sounds
>> > like a lot of work for the time we have got left in the Buster
>> > release
>> > cycle.
>> 
>> In my understanding there is no need to patch any of the reverse
>> dependencies. Currently there are binary packages called python-numpy
>> and python3-numpy, built from a source package called python-numpy.
>> In
>> my understanding the proposed change is to keep having the exact same
>> binary packages, just built from two different source packages
>> (python-numpy and python-numpy-legacy or whatever).
>
> Oh, I see what you mean.
>
> So you'd have:
>
> - src:python-numpy-legacy providing python-numpy (<2.0) only
> - src:python-numpy providing python3-numpy (>=2.0) only
>
> Assuming version 2 is when the split happens.
>
> Am I correct?

Yeah, this would be my understanding of the plan. Things could get more
complex if the same split needs to happen at many levels of the stack (a
library that uses numpy is only compatible with numpy <2.0, followed by
another one on the next level down).

-- 
Arto Jantunen

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

#11026

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

On Tue, 16 Oct 2018 at 22:11, <ghisvail@gmail.com> wrote:

> On Tue, 2018-10-16 at 11:45 +0300, Arto Jantunen wrote:
> > ghisvail@gmail.com writes:
> > > Don't get me wrong, I am all in favour for a modern stack,
> > > including
> > > Python 3.
> > >
> > > However, upgrading NumPy et al. to their Python 3 only versions,
> > > introducing new legacy packages for Python 2, and patching the
> > > large
> > > collection of packages relying on the Python 2 versions of these
> > > sounds
> > > like a lot of work for the time we have got left in the Buster
> > > release
> > > cycle.
> >
> > In my understanding there is no need to patch any of the reverse
> > dependencies. Currently there are binary packages called python-numpy
> > and python3-numpy, built from a source package called python-numpy.
> > In
> > my understanding the proposed change is to keep having the exact same
> > binary packages, just built from two different source packages
> > (python-numpy and python-numpy-legacy or whatever).
>
> Oh, I see what you mean.
>
> So you'd have:
>
> - src:python-numpy-legacy providing python-numpy (<2.0) only
> - src:python-numpy providing python3-numpy (>=2.0) only
>

This sort of thing has already happened for astroid, src:astroid builds
python3-astroid 2.0.4-2 and src:astroid2 builds python-astroid 1.6.5-2 (and
something similar for pylint).

Cheers,
mwh

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

#11019

Hi Ghis,

On 16.10.18 08:30, ghisvail@gmail.com wrote:
> On Mon, 2018-10-15 at 22:44 +0200, Steffen Möller wrote:
>> Hello,
>>
>> I am keeping me busy packaging the Orange machine learning library
>> that
>> seems nice (https://orange.biolab.si/#Orange-Features). Now, the
>> test
>> routines demand a matplotlib.pyplot module that is not in version 2
>> that
>> we feature. Version 3 is the current stable release.
> Ack. Thank you for explaining the context.
>
>> Now, I am tempted to create a package matplotlib3 instead of forcing
>> everyone to update from this long term release (see
>> https://matplotlib.org/).
>>
>> Any opinions from your sides?
> How is that going to work without creating package conflicts?
>
> I suppose  the main module is still named "matplotlib" not
> "matplotlib3" in version 3 onwards? So using python3-matplotlib3 would
> be a breach of policy.
Yes. We would need to freely interpret that policy in analogy to Debian 
libraries e.g. for C/C++ or Java.
> Let me ask you this: where is the rush to package this machine learning
> library? Could it wait after the Buster release cycle, where we might
> be in a more comfortable position to upgrade matplotlib?

The short answer is yes. The almost as short one is "Conda has it 
already, use that". The slightly longer answer is that I don't think 
that this is the right thing for Debian to do. We are then shipping an 
old version of matplotlib, i.e. oldstable, with a new release of our 
distribution. I do also think that that long-term support version 2 of 
matplotlib should remain in our distribution. So we would need to find a 
way to support two versions for the same distribution.

Cheers,

Steffen

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

#11020

On Tue, 2018-10-16 at 10:16 +0200, Steffen Möller wrote:
> Hi Ghis,
> 
> On 16.10.18 08:30, ghisvail@gmail.com wrote:
> > On Mon, 2018-10-15 at 22:44 +0200, Steffen Möller wrote:
> > > Hello,
> > > 
> > > I am keeping me busy packaging the Orange machine learning
> > > library
> > > that
> > > seems nice (https://orange.biolab.si/#Orange-Features). Now, the
> > > test
> > > routines demand a matplotlib.pyplot module that is not in version
> > > 2
> > > that
> > > we feature. Version 3 is the current stable release.
> > Ack. Thank you for explaining the context.
> > 
> > > Now, I am tempted to create a package matplotlib3 instead of
> > > forcing
> > > everyone to update from this long term release (see
> > > https://matplotlib.org/).
> > > 
> > > Any opinions from your sides?
> > How is that going to work without creating package conflicts?
> > 
> > I suppose  the main module is still named "matplotlib" not
> > "matplotlib3" in version 3 onwards? So using python3-matplotlib3
> > would
> > be a breach of policy.
> Yes. We would need to freely interpret that policy in analogy to
> Debian 
> libraries e.g. for C/C++ or Java.

I am not quite sure which interpretation you are refering to in this
case. Back to the Debian Python policy, the wording in section 2.2 uses
"should" instead of "must", so there is room for discussion in
exceptional circumstances I guess.

> > Let me ask you this: where is the rush to package this machine
> > learning
> > library? Could it wait after the Buster release cycle, where we
> > might
> > be in a more comfortable position to upgrade matplotlib?
> 
> The short answer is yes.

There you go.

>  The almost as short one is "Conda has it already, use that".

Even better. Or use a virtual environment. Which the majority of
developers do (one or the other).

>  The slightly longer answer is that I don't think 
> that this is the right thing for Debian to do. We are then shipping
> an 
> old version of matplotlib, i.e. oldstable, with a new release of our 
> distribution.

"Old" indeed, but still actively maintained upstream.

>  I do also think that that long-term support version 2 of 
> matplotlib should remain in our distribution. So we would need to
> find a 
> way to support two versions for the same distribution.

I'll ask the same question again: besides your ITP for Orange, is there
anything *already* in the archive in desparate need for an upgrade of
matplotlib to its new major release?

If not, figuring out a way to support both versions can be postponed to
the next release cycle, imo. I don't see where the rush would be. There
is already enough on our plates as far as RC bugs are concerned.

I have already spoken quite a bit, so I'll let others in the team give
their opinions.

Cheers,
Ghis

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

#11021

>> Let me ask you this: where is the rush to package this machine learning
>> library? Could it wait after the Buster release cycle, where we might
>> be in a more comfortable position to upgrade matplotlib?
> The short answer is yes. The almost as short one is "Conda has it 
> already, use that". The slightly longer answer is that I don't think 
> that this is the right thing for Debian to do. We are then shipping an 
> old version of matplotlib, i.e. oldstable, with a new release of our 
> distribution. I do also think that that long-term support version 2 of 
> matplotlib should remain in our distribution. So we would need to find 
> a way to support two versions for the same distribution.

Kind of answering myself - I do not see a rush, either. I was just 
positively surprised about Orange and would like many users to share 
that experience with Buster - not two years later.

How deep is the Python Policy wrt package naming set in stone? Wrt to 
the renaming that Andreas suggested - I would be prepared to work 
through renames of matlibtools to matlibtools2 in all those source trees 
that are incompatible with version 3.

Cheers,

Steffen

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

#11023

On Tue, 2018-10-16 at 10:42 +0200, Steffen Möller wrote:
> > > Let me ask you this: where is the rush to package this machine
> > > learning
> > > library? Could it wait after the Buster release cycle, where we
> > > might
> > > be in a more comfortable position to upgrade matplotlib?
> > The short answer is yes. The almost as short one is "Conda has it 
> > already, use that". The slightly longer answer is that I don't
> > think 
> > that this is the right thing for Debian to do. We are then shipping
> > an 
> > old version of matplotlib, i.e. oldstable, with a new release of
> > our 
> > distribution. I do also think that that long-term support version 2
> > of 
> > matplotlib should remain in our distribution. So we would need to
> > find 
> > a way to support two versions for the same distribution.
> 
> Kind of answering myself - I do not see a rush, either. I was just 
> positively surprised about Orange and would like many users to share 
> that experience with Buster - not two years later.

Looking at their release history [1], the upstream release cadence is
once a month.

Assuming the freeze takes about three months to complete (quite
optimisticly), will upstream be interested in feedback and bug reports
from 3 releases ago? Maybe.

What about a year later? That would be 15 releases ago. I am not too
sure about it. They'll just ask you to use Anaconda [2], which is the
very first entry in their installation instructions.

Don't you think?

[1] https://pypi.org/project/Orange3/#history
[2] https://orange.biolab.si/download/

Cheers,
Ghis

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

#11027

Quoting Steffen Möller <steffen.moeller@uni-rostock.de>:
> Now, I am tempted to create a package matplotlib3 instead of forcing  
> everyone to update from this long term release (see  
> https://matplotlib.org/).
>
> Any opinions from your sides?

I wonder, whether it's easier to wait for buster and then create an
orange backport? I'm sure, immediately after release, we (= Python
teams) will start to drop Python 2 support anyway. In the mean time
new versions of matplotlib and friends, as well as orange, might be
suitable for experimental, so that your packaging work doesn't need
to wait. Orange looks very interesting and is a welcome addition to
Debian, btw.!

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

#11028

> Now, I am tempted to create a package matplotlib3 instead of forcing

please dont. the right course of action is:

- fork src:matplotlib2 from src:matplotlib to only provide the python2 package
- update src:matplotlib to upstream 3.x to provide only py3k modules
(and since there was also a discussion about numpy)
- make src:python-numpy provide only python2 package
- fork src:numpy from src:python-numpy to provide only python3 modules.

since i'm the maintainer of both matplotlib and numpy, i'll take care
of these "transitions"

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

[toc] | [prev] | [standalone]

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

csiph-web