I think we can move the whole modules dviread.py to and texmanager.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 from dviread.py to _dviread.py.
• Update all internal usages to use _dviread.py
• replace the content of dviread.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 for texmanager.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 on Dvi and dviread.PsfontsMap(dviread.find_tex_file("pdftex.map")). Maybe it is enough to provide a Dvi and

@lru_cache(1)
def get_tex_font_map():
    return dviread.PsfontsMap(dviread.find_tex_file("pdftex.map"))

in the public interface?

(gr and wxmplot doesn't seem to use neither dviread or texmanager.)

(I can easily provide a PR for mplcairo 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 for get_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 just PsfontsMap(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 backends that 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 if True will apply find_tex_file(filename)? In that way one can use some other map file, in the (admittedly unlikely) event that pdflatex is not used?

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

Is the PsfontMap 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 keeping make_dvi, get_grey and get_text_width_height_descent as public APIs, and perhaps make_dvi could be replaced by something like get_dvi which returns Dvi(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 remove texmanager from the list).

I'd be OK with privatizing the parts of dviread 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.