As discussed on gitter: so long as we rely on data_files
, this issue, and a large swathe of related problems, is going to be a problem. We opted in the notebook
era, when adding the conf.d
approach (which made everybody a lot happier, to be sure) to continue using them, but the data_files
situation hasn’t improved.
setuptools
, the only python packaging tool that still supports this approach, has marked them in their official docs as deprecated, and poetry
, flit
, and others probably won’t ever support putting untraceable files… somewhere in sys.prefix
.
These thoughts are outlined in this jupyter_server issue, with the argument against being: but it’s so nice for non-python languages and conda
!. True. But the brass tacks of the matter is that we’re unlikely to get off the python/pip bus for the foreseeable future, and that bus could well leave the station at any time, and quickly.
This draft PR shows how we could move forward in a backwards-compatible way that would give python-focused package maintainers a path away from these problems. Being able to point folks to convention-based approaches like poetry
and flit
would make packaging for Jupyter less insular.
The biggest argument against on that PR is, it’s already too hard to keep the n jupyter --paths
straight, this will make it worse! Also true! But I feel like we need to do something.