Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All included backends should work or be removed #1961

Closed
mdboom opened this issue Apr 29, 2013 · 11 comments
Closed

All included backends should work or be removed #1961

mdboom opened this issue Apr 29, 2013 · 11 comments

Comments

@mdboom
Copy link
Member

mdboom commented Apr 29, 2013

For the 1.3 release, I think we should endeavor to have all backends working or removed. My definition of "working" here is a pretty low bar: I mean essentially importing and producing a usable result. I'm not talking about having all the fonts exactly match etc. such as with the known issues with (non-Agg) Wx and Gtk.

Here are the backends that I think are on the short list for removal:

  • emf (requires pyemf, which is not currently available on PyPI)
  • CocoaAgg -- reportedly doesn't import, but I haven't confirmed on a Mac
  • fltk -- pyfltk doesn't have packages for my system (Fedora 18) and there are errors compiling it from source

And one additional suggestion -- it's working, but could be considered obsolete:

  • Qt3Agg -- so much of the world has moved on to Qt4 and beyond, maybe it's time to retire these?

I know the Wx and Gtk backends are probably also low on the popularity list at this time, but they fill a unique niche for by providing better performance over remote X11 connections.

@WeatherGod
Copy link
Member

Backends are an interesting beast. While we have done a fantastic job of
making most users completely unaware of the fact that backends even exist,
we still provide full access to particular backends for a wide variety of
uses. Therefore, if one chooses to use a particular backend, it is
generally going to be for a particular reason related to that backend
(e.g., embedding in an application and such). So, I would propose that any
deprecation of a backend takes two release cycles rather than the normal
one release.

I would probably suggest deprecating Qt3Agg at the next release. There
really isn't a maintenance burden yet, I don't think, and there are still
plenty of systems out there on LTS using Qt3 (particularly the RHEL
systems). I could be convinced otherwise to start the deprecation now,
though.

As for the emf format, it is an odd duck, but for those who do still have
pyemf, it works. I have never gotten fltk working for me (not that I
really tried, though).

@efiring
Copy link
Member

efiring commented Apr 29, 2013

From the present backend_qt.py:

warnings.warn("QT3-based backends are deprecated and will be removed after"
              " the v1.2.x release. Use the equivalent QT4 backend instead.",
              mplDeprecation)

@WeatherGod, you put that in 7 months ago, so I think we should go ahead and remove backend_qt.py in 1.3. The people on old RHEL systems can continue using an older mpl, or they can use a different backend if they update their mpl.

There is a real maintenance burden with all code clutter. I felt it with fltk around the mpl 1.0 release. The last news item on http://pyfltk.sourceforge.net/ is dated August, 2009, so it looks like it has completely stalled. I think we should put in a deprecation warning for 1.3 and remove it in 1.4. If pyfltk somehow springs back to life, there is nothing to prevent us (or rather, some suitably motivated person) from updating backend_fltkagg and restoring it to mpl.

The last pyemf release appears to date back to 2006. It's time to drop backend_emf. Deprecate now, remove in 1.4.

CocoaAgg requires PyObjC; when I try to "pip install pyobjc", it fails. I don't know why. Unlike pyfltk, pyobjc is a live project. CocoaAgg, however, is not a live project, and it is not at all clear that it has ever been used as an alternative backend. From the docstring:

 Notes:
  - Requires PyObjC (currently testing v1.3.7)
  - The Tk backend works nicely on OSX.  This code
    primarily serves as an example of embedding a
    matplotlib rendering context into a cocoa app
    using a NSImageView.

So it sounds to me like if it actually works, it should be migrated out to a cookbook wiki, or an example. ASAP.

I think mpl is at a stage of maturity where it is important to actively trim out clutter and bloat; removing these backends is one part of that process.

@ddale
Copy link
Contributor

ddale commented Apr 29, 2013

Completely agree with Eric's comments about removing the Qt3 backend.

@WeatherGod
Copy link
Member

On Mon, Apr 29, 2013 at 2:30 PM, Eric Firing notifications@github.comwrote:

From the present backend_qt.py:

warnings.warn("QT3-based backends are deprecated and will be removed after"
" the v1.2.x release. Use the equivalent QT4 backend instead.",
mplDeprecation)

@WeatherGod https://github.com/weathergod, you put that in 7 months
ago, so I think we should go ahead and remove backend_qt.py in 1.3. The
people on old RHEL systems can continue using an older mpl, or they can use
a different backend if they update their mpl.

Well, I did say that I could be convinced otherwise. Apparently, I was
convinced at some point and completely forgot about it. Go figure...

@mdboom
Copy link
Member Author

mdboom commented Apr 29, 2013

Ah -- I should have actually looked at the Qt3 backend first ;) So I think we're in agreement on removing it for 1.3, then.

I think I see the argument for making CocoaAgg an example rather than a real backend.

Maybe for EMF and fltk we poll the users list and if no responses, remove them?

EDIT: I meant for EMF and fltk, deprecate.

@Tillsten
Copy link
Contributor

I tried the emf backend recently, but the result was not really useable. Irc, there was no text visible after import into publisher, also the linewidths were not right. I think dropping emf should be ok, it did no seem very useable.

@embray
Copy link
Contributor

embray commented Apr 30, 2013

Problem with deprecation warnings such as the one about QT3 is that people ignore them and go about their business as if things will never change. I recently removed some interfaces from the master branch on pyfits that have been screaming "deprecated" for nearly two years, and sure enough as soon as I removed them lots of code broke.

I think that before removing any deprecated backends it's good to scream about it in release notes, etc. for at least one more release. People will still ignore it but at that point you can really say "Well we gave you fair warning."

@toddrjen
Copy link
Contributor

toddrjen commented May 1, 2013

At the very least the Qt3 backend should be removed before a Qt5 one is added.

@pelson
Copy link
Member

pelson commented May 2, 2013

CocoaAgg requires PyObjC; when I try to "pip install pyobjc", it fails. I don't know why. Unlike pyfltk, pyobjc is a live project. CocoaAgg, however, is not a live project, and it is not at all clear that it has ever been used as an alternative backend.

I installed PyObjC last night and the CocoaAgg backend functions. PyObjC looks like it might have had a bit of a revival (there was talk of it being able to create iPad/iPhone apps, which I think gave it a boost of impetus).
CocoaAgg is not a fully fledged backend (there are no icons nor interactivity) so I would agree that, unless we can find somebody willing to put in a bit of effort to bring the GUI up to TkAgg/Gtk3Agg/Qt4Agg/WxAgg/MacOs quality, we move the code into an example in examples/user_interfaces.

I propose we do that for v1.4 putting in a strongly worded CocoaAgg backend deprecation warning (which encourages contributors to bring the CocoaAgg backend up to standards) for v1.3. I see no reason, since it is functional has not had a development burden recently, for us to remove it for v1.3. Thoughts?

@efiring
Copy link
Member

efiring commented May 2, 2013

@pelson, your proposal is OK with me.

@mdboom
Copy link
Member Author

mdboom commented May 21, 2013

Closed by #2026.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants