When software that uses platformdirs is installed by Homebrew, it should be smart enough to look for site configuration that is installed/managed by Homebrew, which may be different from the location that the OS would normally specify. Ideally, the software should check both locations if they are different from each other.
Background
Homebrew is a package manager for macOS, with Linux support as well. In order to avoid conflicting with the system utilities provided by Apple, Homebrew keeps all of its files (including Homebrew-installed software requested by the user) under a root directory known as the "prefix". This prefix can be configured by the user when Homebrew is installed, but there are three different defaults, depending on the system: /usr/local for macOS on Intel, /opt/homebrew for macOS on Apple Silicon, or /home/linuxbrew/.linuxbrew for Linux. The Homebrew FAQ explains the reasons for these different default values.
Example
To provide a concrete example, JupyterLab is a well-known system that composes together many pluggable components. (It also uses platformdirs to determine the location of site configuration data.) JupyterLab is kind of like an IDE that supports many different programming languages and functionalities; in order to add support for a new programming language, JupyterLab requires a "kernel": a configuration file that describes how find the language executable on the computer.
It should be possible for a user to install JupyterLab from Homebrew -- and indeed, it is already possible to do so. It should also be possible for a user to install other programming languages from Homebrew, and install a kernel for JupyterLab for each of these languages so that JupyterLab can find and use them. However, because Homebrew keeps all its files under the prefix directory, these kernels need to live there -- and JupyterLab needs to be able to find them. On an Apple Silicon system, the kernel files would live in /opt/homebrew/etc/jupyter/kernels. But because platformdirs is not aware of Homebrew, it returns /Users/$USER/Library/Jupyter for the site configuration directory; meaning that these kernels installed by Homebrew will not be found.
Workaround
In this specific example, it's possible to tell JupyterLab how to find these kernels by setting the JUPYTER_DATA_DIR environment variable to /opt/homebrew/etc/jupyter before running JupyterLab. However, it seems to me that the main purpose of a project like platformdirs is to have standardized locations for configuration files, without needing workarounds like this. Therefore, the existence of this workaround does not invalidate this bug report.
Problem
When software that uses
platformdirsis installed by Homebrew, it should be smart enough to look for site configuration that is installed/managed by Homebrew, which may be different from the location that the OS would normally specify. Ideally, the software should check both locations if they are different from each other.Background
Homebrew is a package manager for macOS, with Linux support as well. In order to avoid conflicting with the system utilities provided by Apple, Homebrew keeps all of its files (including Homebrew-installed software requested by the user) under a root directory known as the "prefix". This prefix can be configured by the user when Homebrew is installed, but there are three different defaults, depending on the system:
/usr/localfor macOS on Intel,/opt/homebrewfor macOS on Apple Silicon, or/home/linuxbrew/.linuxbrewfor Linux. The Homebrew FAQ explains the reasons for these different default values.Example
To provide a concrete example, JupyterLab is a well-known system that composes together many pluggable components. (It also uses
platformdirsto determine the location of site configuration data.) JupyterLab is kind of like an IDE that supports many different programming languages and functionalities; in order to add support for a new programming language, JupyterLab requires a "kernel": a configuration file that describes how find the language executable on the computer.It should be possible for a user to install JupyterLab from Homebrew -- and indeed, it is already possible to do so. It should also be possible for a user to install other programming languages from Homebrew, and install a kernel for JupyterLab for each of these languages so that JupyterLab can find and use them. However, because Homebrew keeps all its files under the prefix directory, these kernels need to live there -- and JupyterLab needs to be able to find them. On an Apple Silicon system, the kernel files would live in
/opt/homebrew/etc/jupyter/kernels. But becauseplatformdirsis not aware of Homebrew, it returns/Users/$USER/Library/Jupyterfor the site configuration directory; meaning that these kernels installed by Homebrew will not be found.Workaround
In this specific example, it's possible to tell JupyterLab how to find these kernels by setting the
JUPYTER_DATA_DIRenvironment variable to/opt/homebrew/etc/jupyterbefore running JupyterLab. However, it seems to me that the main purpose of a project likeplatformdirsis to have standardized locations for configuration files, without needing workarounds like this. Therefore, the existence of this workaround does not invalidate this bug report.