Find more elegant solution for the cache file name

[DropD]

The purpose of this file name is to separate entry point caches from different python environments.
As such, it must be specific enough to get the same entry points from the same plugin host always.

The following cases must be covered, assuming plugin_host uses entry points from plugin1 and plugin2 and provides a cli with a list-plugins subcommand:

pip2 install plugin_host plugin1 plugin2
plugin_host list-plugins
 * plugin1
 * plugin2

path/to/python /path/to/plugin_host_cli list-plugins
 * plugin1 
 * plugin2

path/to/python2 /path/to/plugin_host_cli list-plugins
 * plugin1 
 * plugin2

path/to/python2.7 /path/to/plugin_host_cli list-plugins
 * plugin1 
 * plugin2

workon py3
(py3) pip install plugin_host pluginA pluginB plugin1
(py3) plugin_host list-plugins
 * plugin1
 * pluginA
 * pluginB

etc.
The above assumes that plugins use the PEP-518 way of specifying build dependencies (with a pyproject.toml) and that they use the reentry_register keyword in setup.

But there is more:

workon this
(this) pip install -e ./reentry
(this) pip install -e ./plugin_host
(this) pip install -e ./plugin1
(this) pip install plugin2
(this) plugin_host list-plugins
 * plugin1
 * plugin2

(this) workon that
(that) pip install -e ./reentry
(that) pip install -e ./plugin_host
(that) pip install plugin1 pluginA
(that) plugin_host list-plugins
 * plugin1
 * pluginA

And all permutations of the above, of course, including upgrading reentry at a later point.

Currently this is achieved using dirname(sys.executable) + _ + PY2 | PY3, because it is the only way to cover all the above cases found so far. Attempts to use the location where reentry or it's CLI is installed have failed, because that location is different when installed as a build time dependency. Yet, maybe a better way exists.

Solutions to try:

• distutils.sysconfig.get_python_lib() (and equivalent in py3)

[dev-zero]

there are some other issues with the current naming scheme:

1. if one of the path components is a symlink, reentry will generate two config files at some point, example:

   /users/tiziano/.config/reentry/data/users.tiziano.work.aiida.aiida_core.venv.bin.python3
   /users/tiziano/.config/reentry/data/scratch.tiziano.work.aiida.venv2.bin.python2
   

   here the folder is actually located in /scratch/tiziano/work/aiida with a symlink to it in /users/tiziano/work/aiida. This can be easily mitigated by fully resolving all symlinks.

2. Using something like CPython instead of just Python may be a good idea to distinguish between implementations of Python.

3. For deeply nested paths you might run into a max-path-length problem on certain OS. Hashing the full name could help.

4. Instead of using ~/.config wouldn't it be more appropriate to use ~/.local/share (respectively $XDG_DATA_HOME if defined) as a base-dir instead, or even the $XDG_CACHE_HOME since it is actually a cache file?

[DropD]

Thanks @dev-zero! I accepted your PR

[ltalirz]

Can this now be closed?

[dev-zero]

I doubt it. While my PR solved some aspects tied to this issue, the main point of it is not solved yet.