I think we can move the whole modulesdviread.py to andtexmanager.py to private. This all is just helper functionality for our TeX support. There is no need for a matplotlib user to use these directly.

Things to do:

• copy everything fromdviread.py to_dviread.py.
• Update all internal usages to use_dviread.py
• replace the content ofdviread.py with

  from matplotlib._dviread import *from matplotlib import _api_api.warn_deprecated("3.6", f"The module {__name__} is deprecated")

  This will give users that might have used that functionality for their own purpose a warning that we will no longer provide it.
• Add a deprecation note in doc/api/next_api_changes/deprecations

Same fortexmanager.py.

OK! Great! Much easier that to try to resolve the cyclic import issues, I've been playing around with. :-)

I am not entirely convinced that dviread should be made private, because it is more or less effectively required to implement usetex in third-party backends (e.g., mplcairo), and API changes have not been particularly onerous on that submodule. But I could change my mind, depending on the arguments...

OK! I'll hold my horses then.

I checked mplcairo and it seems to rely onDvi anddviread.PsfontsMap(dviread.find_tex_file("pdftex.map")). Maybe it is enough to provide aDvi and

@lru_cache(1)defget_tex_font_map():returndviread.PsfontsMap(dviread.find_tex_file("pdftex.map"))

in the public interface?

(gr and wxmplot doesn't seem to use neitherdviread ortexmanager.)

(I can easily provide a PR formplcairo and any other backends that may show up. The main problem, I guess, is to synchronize releases.)

I still made the changes while I remembered them. No deprecation yet though and no api-change-info so no one will merge by mistake...

(I will also add documentation forget_tex_font_map if that is deemed a useful approach.)

Edit: I will also rename_dviread_vf.py to_vf.py.

Thanks for taking backcompat seriously :)
Rather than a separate get_tex_font_map, I guess a solution would be to expand the signature of PsfontsMap justPsfontsMap(filename=None) and map None to find_tex_file("pdftex.map"), which is after all the main (only?) use case of the class -- and the class basically exposes no API other than being a dict-like. This way you don't need a function that returns a private class (that's possible, but always a bit awkward).

wxmplot is not (AFAIK) a backend in itself, but rather a set of tools built around the wx/wxagg backend.
From a quick look, the gr backend can get away with nothing from dviread because (like agg) it shells out to dvipng (via TexManager.get_grey) to rasterize the dvi, but that doesn't work for vector backends (e.g., generating pdf/ps/svg from mplcairo) because they need to extract the individual glyphs from the dvi file to position them in the output file.

Synchronizing the releases across backends is another issue with this kind of changes, but I think that's reasonably doable; the number of truly independent third-party backendsthat reimplement the rendering themselves (not just the GUI integration) is probably not that big and we can try to reach all of them. My point was really more the need for required functionality to stay available.

@anntzer or should one add a second flag,find_tex_file=False, which ifTrue will applyfind_tex_file(filename)? In that way one can use some other map file, in the (admittedly unlikely) event thatpdflatex is not used?

I think I'll go with that for now and can easily change it, if the original suggestion seems better.

Is thePsfontMap change an API or a user change? API, right? development?

Btw, this is now recreated so that_dviread.py and_vf.py should keep all git history. Hence, the multiple commits.

Am I correct in assuming that the moved private methods does not have to be mentioned not deprecated?

I think I would keep dviread as a single file and just add a leading underscore to whatever APIs we want to privatize. Splitting over two files just makes things more confusing. (I know, I did split mathtext into two files for the privatization of most of the API, but perhaps I shouldn't have?)

As for texmanager, the TexManager class effectively remains public (via get_texmanager()) so I don't think it makes much sense to make the module private (you can think of it as "how would you document the return type of get_texmanage()"?); I think the more relevant point would be to make some of TexManager's methods private -- we can probably get away with just keepingmake_dvi,get_grey andget_text_width_height_descent as public APIs, and perhapsmake_dvi could be replaced by something likeget_dvi which returnsDvi(make_dvi(...)).

OK! I basically went with#16181, so I do not have any strong opinions myself. I'll leave this as is for now and maybe@timhoffm can provide some feedback as well (and possibly removetexmanager from the list).

I'd be OK with privatizing the parts ofdviread as long as there is a clear consensus to what should be done.

(I think splitting can be a good thing, especially if the files are really long, which is maybe not the case here.)

I'll close this for now, but can start over if there is a consensus about what should be deprecated.