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
flit, and others probably won’t ever support putting untraceable files… somewhere in
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
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.