in Debian we also use MATPLOTLIBDATA during matplotlib build, in order to point to a not-yet-installed mpl-data directory, for example:

to build the documentation:

        # build the doc
        MPLCONFIGDIR=. MATPLOTLIBDATA=$(CURDIR)/lib/matplotlib/mpl-data/ PYTHONPATH=$(CURDIR)/build/lib.$(PY_PLATFORM)-$(DEFPY) $(MAKE) -C doc html

to run the test suite:

        -PYTHONPATH=$(shell python$* -c "from distutils.command.build import build ; \
                                        from distutils.core import Distribution ; \
                                        b = build(Distribution()) ; \
                                        b.finalize_options() ; \
                                        print(b.build_platlib)") \
        MATPLOTLIBDATA=$(CURDIR)/lib/matplotlib/mpl-data/ \
        MPLCONFIGDIR=. \
                xvfb-run -a python$* tests.py --no-network --verbose --full-trace

        -PYTHONPATH=$(shell python$*-dbg -c "from distutils.command.build import build ; \
                                            from distutils.core import Distribution ; \
                                            b = build(Distribution()) ; \
                                            b.finalize_options() ; \
                                            print(b.build_platlib)") \
        MATPLOTLIBDATA=$(CURDIR)/lib/matplotlib/mpl-data/ \
        MPLCONFIGDIR=. \
                xvfb-run -a python$*-dbg tests.py --no-network --verbose --full-trace
        rm -f matplotlibrc

how would we achieve the same result when MATPLOTLIBDATA is gone?

Is installing Matplotlib in a venv and building the docs from there acceptable for Debian?
Note that our devel guides strongly encourage doing stuff with an installed Matplotlib.

Or apply your mpl-data-moving patch after building the docs.

Or patch doc/conf.py to make it apply a patch to matplotlib/__init__.py to find the sample data where needed.

sadly it's not possible to build mpl in a venv and use it to build the documentation (it's just how the debian packaging system works). i understand your suggestions, but i have to make something acceptable by the debian ecosystem, in this case:

• patches get applied after unpacking the upstream source code from the released tarball
• python modules are built with (setup.py build)
• tests are run against the just-built code
• the documentation is pointing the PYTHONPATH to the just-built code
• modules are installed in a temporary location (setup.py install) to be later wrapped up in a file.deb we can ship

if you really want to get rid of MATPLOTLIBDATA, i'll just keep it around as a debian patch, no bid deal

Can you point to me where these rules are listed?
I don't want to make life exceedingly hard for debian packagers, but having some idea of what are debian's policies would help...

Edit: Or perhaps you can patch get_data_path() to add Debian's path as a last fallback. This way, when setting PYTHONPATH to the just-built Matplotlib, it'll use the "normal" path, but when the end-user is importing Matplotlib, the last-fallback path will be used.

Or as suggested above you can patch doc/conf.py to do something like

import matplotlib; matplotlib.get_data_path = lambda: <the normal data path>

Tests are run against the installed matplotlib in Fedora during build. The reason that MATPLOTLIBDATA is used is because everything is installed in a self-contained destdir. Only specifying the patched path as the fallback only will not work because of this, as we don't really want to include that build root path in the installed version.

Would patching to

path = Path(__file__) / "../../(didn't count)/share/data/matplotlib"

work?
(i.e. the relative path of mpl-data relative to matplotlib/__init__.py in the destdir, in whatever way Fedora wants to arrange it)

Actually, though I haven't looked into the history of it, I think the main reason for separating things is to avoid installing twice for Python 2 and 3, but with Matplotlib 3 only supporting Python 3 now...

Re-pinging @QuLogic @sandrotosi after #11241 (comment). Thanks in advance for your input.

I think that is reasonable and would work fine; the self-contained destdir is supposed to mirror the final install exactly after all.

I am -0.5 on this. I don't see much of an upside and see a downside of making the debian packaging a bit more annoying.

The upside is ultimately switching to https://docs.python.org/3/library/importlib.html#module-importlib.resources (Py3.7+) instead of having to bother with _get_data_path at all, and completely remove the rcparam...

FWIW the final patch would make _get_data_path something like (just)

    global _data_path_cm
    _data_path_cm = ExitStack()  # This keeps the contextmanager open.
    return _data_path_cm.enter_context(
        importlib.resources.path('matplotlib', 'mpl-data'))

and not even store it in rcParams (because it doesn't make sense to let the user modify it later anyways -- many things, e.g. the included font paths, are set in stone at import time).

let me just re-state what i said before: i totally understand if you want to get rid of MATPLOTLIBDATA env var to make mpl code easier to maintain. OTOH we kinda like the ability to specify where the mpl-data is at runtime, without patching anything (more than we already do ;) ) or setting a list of "weirdly looking" paths.

i'm just fine to come up with a debian-specific patch to support our needs if you ultimately decide to drop MATPLOTLIBDATA

@tacaswell Are you willing to revisit this based on the comments so far?

Happy to help with the Debian-specific patch if needed.

@sandrotosi this is coming for 3.1 (next month-ish).

One minor inconvenience here is that if you're running with a patched path (using Path(__file__).parent ...), then you can't override where an editable install is looking for data. This is something you might do while testing backports, or (in my case), new images for FreeType 2.9.1.

But the baseline images aren't found relative to the data dir? I'm not sure what the issue is, but would be happy to hear more.