Replace deprecated appdirs with platformdirs, fix config path lookup with non conda-based environments

[agriyakhetarpal]

Description

As the appdirs project is no longer maintained (ActiveState/appdirs@8734277), this pull request swaps out the dependency to use platformdirs. Additionally, it changes empack's DEFAULT_CONFIG_PATH lookup to also cater to virtual environments that are not managed by conda or equivalent tools, in light of matplotlib/matplotlib#29506 where a problem was noticed when using pyenv-based Python installations/interpreters.

Additional context

• The platformdirs documentation: https://platformdirs.readthedocs.io/en/stable/
• https://alexwlchan.net/til/2025/platform-specific-dirs/

[agriyakhetarpal]

Should I add a CHANGELOG entry as well here, or will it be picked up by the PR title automatically? It would be nice to get this PR in a release, but there's no hurry :D

[martinRenou]

Should I add a CHANGELOG entry as well here, or will it be picked up by the PR title automatically?

It will be picked up automatically :) Happy to make a patch release with this! Thanks!

[martinRenou]

It seems the CI says appdirs is still being used

[agriyakhetarpal]

This will be addressed by emscripten-forge/pyjs-code-runner#15, marking for completeness :)

[martinRenou]

Actually I believe the change is not correct. It does not respect the current conda environment and it installs at the root config dir: '/home/martin/.config/empack' for me, while it should respect that I'm using micromamba here so /home/martin/micromamba/envs/whatever/share/empack or /home/martin/micromamba/envs/whatever/.config/empack

[agriyakhetarpal]

I shall take a look. We might need the same changes across https://github.com/emscripten-forge/pyjs-code-runner, as it uses appdirs as well: https://github.com/emscripten-forge/pyjs-code-runner/blob/0d36f65af4965ee34bf13690bb8098f8bca8b97d/pyproject.toml#L25C5-L25C12

[agriyakhetarpal]

Actually I believe the change is not correct. It does not respect the current conda environment and it installs at the root config dir: '/home/martin/.config/empack' for me, while it should respect that I'm using micromamba here so /home/martin/micromamba/envs/whatever/share/empack or /home/martin/micromamba/envs/whatever/.config/empack

This would be by design of platformdirs. If we want DEFAULT_CONFIG_PATH to be different per installation/per micromamba environment instead of a global one, we would need to set it to os.environ["MAMBA_ROOT_PREFIX"] / "share". Either way, sys.prefix isn't a nice idea because it varies, as we have noticed. What do you think?

[martinRenou]

I'm surprised that sys.prefix isn't set properly when using pyenv, isn't it using the right Python?

[agriyakhetarpal]

I'm surprised that sys.prefix isn't set properly when using pyenv, isn't it using the right Python?

I'm surprised, too, as I just installed pyenv for the first time and it's the same as Python elsewhere (from Homebrew/conda/etc.):

'/opt/homebrew/opt/python@3.10/Frameworks/Python.framework/Versions/3.10

Something else must be at play.

[agriyakhetarpal]

As we want to ensure that a config file must be tied to the current installation of empack and hence to a specific conda/mamba/micromamba/venv env, is to store the config file at empack.__file__, next to __init__.py, which would always be consistent.

[agriyakhetarpal]

I hope 8739917 is acceptable! I tried it out locally, and it passes the test suite. With this commit, the empack_config.yaml file will be checked for in this location:

```/home/martin/micromamba/envs/whatever/lib/python3.X/site-packages/empack/empack_config.yaml`

which, I feel, is better than having to deal with sys.prefix, or $CONDA_PREFIX/share, or $MAMBA_PREFIX/share separately, because it's possible to use empack with venvs, outside of micromamba. I think we should be good to go after emscripten-forge/pyjs-code-runner#15 is merged, as it is pulled from Git.

[martinRenou]

I hope I won't be too annoying to you on this. I have a preference for this to stay 🫤

I believe we should make sure we can find this path when using pyenv.

It seems jupyter has something like that https://github.com/jupyter/jupyter_core/blob/main/jupyter_core/paths.py#L102 for finding whether or not it should use user-level paths or conda environment paths.

[agriyakhetarpal]

I hope I won't be too annoying to you on this.

Absolutely not! :D I'd also love to ensure pyenv works and not move anything else. Let me port Jupyter's thing here, then.

[agriyakhetarpal]

Okay, so, based on that assessment – this means that usage of empack has been broken outside conda/mamba/micromamba, as pyenv doesn't do anything special – any virtual environment with virtualenv/venv/uv would face or have faced this problem, and that explains why we faced this in CircleCI.

Could you check 273966b? I've ported over Jupyter's logic, but I don't know if the license notes would be needed. This seems to resolve the issue locally:

>>> from empack.pack import DEFAULT_CONFIG_PATH
>>> DEFAULT_CONFIG_PATH

now gets us

PosixPath('/Users/agriyakhetarpal/.pyenv/versions/3.10.4/share/empack/empack_config.yaml')

while retaining the behaviour required by micromamba, as you suggested, which is at

PosixPath('/opt/homebrew/Caskroom/miniforge/base/share/empack/empack_config.yaml'

[martinRenou]

@agriyakhetarpal it seems you need to run black on the Python code to lint it.

Also how about we install appdirs on the CI, just to get it running for now, not waiting for a pyjs update?

[agriyakhetarpal]

Thanks! Addressed both points.

[martinRenou]

Sorry, it seems there is a last linting issue 😓

[agriyakhetarpal]

Argh, strange that it didn't happen locally 😅 Addressed with 3b3a32e.

[martinRenou]

Thanks!