mpl 2.1 + subprocess32

Development matplotlib-devel
1

Folks,

With 2.0 we picked up subprocess32 (
https://pypi.python.org/pypi/subprocess32/) to be able to use the improved
subprocess module, however this has caused several problem with [1, 2] due
to a bug in the release version and wheels not being published on pypi.
The bug is reportedly fixed on master [4] and Mathew Brett has provided
them with wheel-building machinery [3], but there has been no motion on
that sense May.

I think our options are:

- document the known issues (meaning wheel-installing mac users have to
install xcode and people on very old linux need to install from the
subprocess32 master branch, and general linux users need to have a gcc
installed)
- hope subprocess32 does a release and adopt Matthew's wheels in the next
month
- vendor the master branch (is there a way we can do this _just_ for the
wheels without actually vendoring it in the source tree?)
- change dependencies

After 2.1 we won't have the last option until 2.2 so if we want to do that,
it needs to be done this month.

If anyone is motivated to work on changing the dependency, please do so
otherwise I am inclined to go with the first option.

Tom

[1] https://github.com/matplotlib/matplotlib/issues/8361
[2] https://github.com/matplotlib/matplotlib/issues/8433
[3] https://github.com/google/python-subprocess32/issues/14
[4] https://github.com/google/python-subprocess32/issues/12
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170730/adc804f9/attachment.html>

2

Hi,

Folks,

With 2.0 we picked up subprocess32
(https://pypi.python.org/pypi/subprocess32/) to be able to use the improved
subprocess module, however this has caused several problem with [1, 2] due
to a bug in the release version and wheels not being published on pypi. The
bug is reportedly fixed on master [4] and Mathew Brett has provided them
with wheel-building machinery [3], but there has been no motion on that
sense May.

I think our options are:

- document the known issues (meaning wheel-installing mac users have to
install xcode and people on very old linux need to install from the
subprocess32 master branch, and general linux users need to have a gcc
installed)
- hope subprocess32 does a release and adopt Matthew's wheels in the next
month
- vendor the master branch (is there a way we can do this _just_ for the
wheels without actually vendoring it in the source tree?)
- change dependencies

After 2.1 we won't have the last option until 2.2 so if we want to do that,
it needs to be done this month.

If anyone is motivated to work on changing the dependency, please do so
otherwise I am inclined to go with the first option.

I'd be really sad if we went for option 1. I'm particularly
interested in installations for new users, and these are often a) via
pip with b) Python 2.7 and b) without a compiler set up. So this is a
painful hurdle, often for those least adapted to clear it...

I'm happy to do donkey work if someone can point me the way forward to
replacing the dependency.

Cheers,

Matthew

···

On Sun, Jul 30, 2017 at 4:20 AM, Thomas Caswell <tcaswell at gmail.com> wrote:

3

Another possible solution could be to drop the dependency on subprocess32
but retain the use of it in *compat/subprocess.py *and fallback to regular
subprocess if not found and then document that if a user sees
https://github.com/matplotlib/matplotlib/issues/5314 they should install
subprocess32. There should be few issues with dropping the dependency on
Linux as the main bug it resolves is OSX specific.

Furthermore 5314 should have been resolved in python 2.7.12 so the surface
for seeing the bug on OSX is getting smaller. Unfortunately Apple still
ships python 2.7.10 as the default python on OSX in Sierra (10.12)

Jens

···

On Tue, 1 Aug 2017 at 12:54 Matthew Brett <matthew.brett at gmail.com> wrote:

Hi,

On Sun, Jul 30, 2017 at 4:20 AM, Thomas Caswell <tcaswell at gmail.com> > wrote:
> Folks,
>
> With 2.0 we picked up subprocess32
> (https://pypi.python.org/pypi/subprocess32/) to be able to use the
improved
> subprocess module, however this has caused several problem with [1, 2]
due
> to a bug in the release version and wheels not being published on pypi.
The
> bug is reportedly fixed on master [4] and Mathew Brett has provided them
> with wheel-building machinery [3], but there has been no motion on that
> sense May.
>
> I think our options are:
>
> - document the known issues (meaning wheel-installing mac users have to
> install xcode and people on very old linux need to install from the
> subprocess32 master branch, and general linux users need to have a gcc
> installed)
> - hope subprocess32 does a release and adopt Matthew's wheels in the
next
> month
> - vendor the master branch (is there a way we can do this _just_ for the
> wheels without actually vendoring it in the source tree?)
> - change dependencies
>
> After 2.1 we won't have the last option until 2.2 so if we want to do
that,
> it needs to be done this month.
>
> If anyone is motivated to work on changing the dependency, please do so
> otherwise I am inclined to go with the first option.

I'd be really sad if we went for option 1. I'm particularly
interested in installations for new users, and these are often a) via
pip with b) Python 2.7 and b) without a compiler set up. So this is a
painful hurdle, often for those least adapted to clear it...

I'm happy to do donkey work if someone can point me the way forward to
replacing the dependency.

Cheers,

Matthew
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170801/b8dff0e4/attachment.html&gt;

4

Another possible solution could be to drop the dependency on subprocess32
but retain the use of it in compat/subprocess.py and fallback to regular
subprocess if not found and then document that if a user sees
https://github.com/matplotlib/matplotlib/issues/5314 they should install
subprocess32. There should be few issues with dropping the dependency on
Linux as the main bug it resolves is OSX specific.

Furthermore 5314 should have been resolved in python 2.7.12 so the surface
for seeing the bug on OSX is getting smaller.

Excellent news!

Unfortunately Apple still
ships python 2.7.10 as the default python on OSX in Sierra (10.12)

The last time I looked into this, a default install of matplotlib into
system Python gets ignored because of the extra libraries "feature"

Is that no longer true?

Cheers,

Matthew

···

On Tue, Aug 1, 2017 at 12:30 PM, Jens Nielsen <jenshnielsen at gmail.com> wrote:

5

I think it still true, I guess you can hack sys.path but perhaps we don't
need to worry about that

···

On Tue, 1 Aug 2017 at 13:57 Matthew Brett <matthew.brett at gmail.com> wrote:

On Tue, Aug 1, 2017 at 12:30 PM, Jens Nielsen <jenshnielsen at gmail.com> > wrote:
> Another possible solution could be to drop the dependency on subprocess32
> but retain the use of it in compat/subprocess.py and fallback to regular
> subprocess if not found and then document that if a user sees
> https://github.com/matplotlib/matplotlib/issues/5314 they should install
> subprocess32. There should be few issues with dropping the dependency on
> Linux as the main bug it resolves is OSX specific.
>
> Furthermore 5314 should have been resolved in python 2.7.12 so the
surface
> for seeing the bug on OSX is getting smaller.

Excellent news!

> Unfortunately Apple still
> ships python 2.7.10 as the default python on OSX in Sierra (10.12)

The last time I looked into this, a default install of matplotlib into
system Python gets ignored because of the extra libraries "feature"

Which Python · MacPython/wiki Wiki · GitHub

Is that no longer true?

Cheers,

Matthew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170801/b4bc3cb7/attachment-0001.html&gt;

6

Hi,

Folks,

With 2.0 we picked up subprocess32
(https://pypi.python.org/pypi/subprocess32/) to be able to use the

improved

subprocess module, however this has caused several problem with [1, 2] due
to a bug in the release version and wheels not being published on pypi.

The

bug is reportedly fixed on master [4] and Mathew Brett has provided them
with wheel-building machinery [3], but there has been no motion on that
sense May.

I think our options are:

- document the known issues (meaning wheel-installing mac users have to
install xcode and people on very old linux need to install from the
subprocess32 master branch, and general linux users need to have a gcc
installed)
- hope subprocess32 does a release and adopt Matthew's wheels in the next
month
- vendor the master branch (is there a way we can do this _just_ for the
wheels without actually vendoring it in the source tree?)
- change dependencies

After 2.1 we won't have the last option until 2.2 so if we want to do

that,

it needs to be done this month.

If anyone is motivated to work on changing the dependency, please do so
otherwise I am inclined to go with the first option.

I'd be really sad if we went for option 1. I'm particularly
interested in installations for new users, and these are often a) via
pip with b) Python 2.7 and b) without a compiler set up. So this is a
painful hurdle, often for those least adapted to clear it...

I'm happy to do donkey work if someone can point me the way forward to
replacing the dependency.

I guess the crude but effective solution would be to fork the subprocess32
repo, make sure the patch you want is applied, then rename the package to
subprocess32_for_matplotlib and upload that to pypi. (Later once they
release a fix you can upload a new version that just depends on and
reexports the real subprocess32.)

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170801/0d4a3af2/attachment.html&gt;

···

On Aug 1, 2017 3:54 AM, "Matthew Brett" <matthew.brett at gmail.com> wrote:
On Sun, Jul 30, 2017 at 4:20 AM, Thomas Caswell <tcaswell at gmail.com> wrote: