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
pythonPackages.matplotlib: enable tk backend by default #51344
Conversation
You mean interactive backend. There are, of course, working non-interactive backends (e.g. agg). We are already unconditionally providing "MacOSX" backend on macOS, so it should be fine to have a working interactive backend on Linux too. And since macOS already has one, it doesn't need tk enabled by default. |
2015e4c
to
b70d345
Compare
Yeah that is what I mean. I disabled tk for darwin and as a bonus (side-effect of doing the change in @GrahamcOfBorg build python2.pkgs.matplotlib python3.pkgs.matplotlib |
I don't think we should enable this back-end. Matplotlib as is can be used for plotting, but just not for interactive plots. If one wants interactive plots, one can choose to override matplotlib, or simply add the dependencies (e.g. Longer-term we should get rid of the options, and simply have ways of saying how an environment should be extended when a certain option (a back-end) is desired. |
Yes, matplotlib can be used for non-interactive plotting. But I think at least as much if not more of the use cases are interactive. With the current situation, this can be very confusing for users who expect Most of the closure size increase should not be unique to matplotlib for most users. I think it is very much worth it. |
@FRidh I had the same idea, but if we really believed that matplotlib should have no windowed interactive backends by default, we would also want to disable cocoa on darwin by default... |
We currently do not build mathplotlib with any backend. This can be very confusing for users. They will try to use matplotlib and it will simply display nothing (see NixOS#51337). We should ship at least one backend. `tk` was chosen somewhat arbitrarily. The gtk backend is problematic (see NixOS#50959 (comment)) so tkinter seems like a good choice. There is already a backend provided on darwin so there is no reason to include tk there.
1aaf4d4
to
dca6628
Compare
@FRidh is this still a hard "no" from you? |
I definitely get a Tk window when I add
I didn't get it directly to work with |
Thats apparently because
But when tkinter was present at compile time of matplotlib, that does work. |
I just ran into this as well and can confirm that, even when having tkinter in the python environment, a |
Turns out it actually enabled the
Indeed, so it seems this backend (just as Cocoa) actually need to be build. Go for it, but include this observation that these two backends, contrary to the others, require building. |
I just encountered such problems when testing osmnx for #57426. That package really wants to have a working graphical backend for matplotlib. And simply overriding with osmnx.override rec {
matplotlib = super.matplotlib.override { enableTk = true; };
descartes = super.descartes.override { inherit matplotlib; };
geopandas = super.geopandas.override { inherit descartes; };
} I think this PR is alright like this, the slight closure size increase is worth the reduced trouble for users. If there are no good objections, I'll merge this today. |
Motivation for this change
We currently do not build mathplotlib with any backend. This can be very
confusing for users. They will try to use matplotlib and it will simply
display nothing (see #51337). We should ship at least one backend.
tk
was chosen somewhat arbitrarily. The gtk backend is problematic (see
#50959 (comment))
so tkinter seems like a good choice.
Closure size before: 256190712
After: 275376184 (7.5% increase)
CC @lovek323
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)