A corner case is where the package is importable because it is on $PYTHONPATH and so the $virtual_env at runtime is different than the one at install time. That is why it might be useful to store the data directory per-package.
wheel.install.get_install_paths(package_name) shows where things would be installed according to wheel. It comes from a call to distutils. pip has its own implementation. On my machine data goes into $virtualenv in a virtualenv and into /usr on system python.
On Fri, 14 Sep 2018 at 16:03, Daniel Holth <dholth@gmail.com> wrote:
>
> It can be hard to predict where data went at runtime.
I don't think it's "hard to predict". I *do* think it's badly
documented/not standardised. See my previous note - pip installs into
the install_data location that setuptools/distutils chooses. Ideally:
a) Setuptools and/or distutils would document where that is clearly
and in an easy to find location.
b) There should be a standard defining "schemes" like this so that the
choices aren't implementation-defined (by pip, setuptools and
distutils in some weird combination).
Of course "there should be..." means "someone who cares enough needs
to invest time in..." :-(
> Maybe we could record its path in .dist-info during the install. I think it may also not be clear how to put files into wheel's data directory from setup.py.
Better would be to have a supported library that exposes the logic pip
uses (or as I said above, the standard-defined logic) to determine
such paths. See https://github.com/pypa/pip/issues/5191
> If we added more categories it would allow the installer to override e.g. just the config directory rather than copying a Unix-like tree under data/ onto the install path.
That's a reasonable but somewhat unrelated suggestion. I don't think
it's needed for the OP's use case, but it may well be helpful for
others.
Paul