Currently the logic for importing the libsymspg library goes like:

• Try to import _spglib which uses LD_LIBRARY_PATH, system library search, (if patched, RPATH) to link to libsymspg
• if it fails, try to load the bundled library and then import _spglib again

This generally works, but there is no mechanism to switch between these preferences, even if we switch the order around.

Some approaches we can consider:

Control via environment variable

This is the most straightforward to implement, but could be troublesome for the user to control, e.g. in a jupyter notebook.

Control via module variable

This needs more research on how to design. So far I can think of 2 methods:

• define a variable at the __init__.py level and do not auto-import spglib.spglib. Not ideal because it breaks API
• use importlib with global/manual cache instead of import and redirect internal usage of _spglib to that function. Complicated, but might be the most robust solution

Separate the python libraries

The idea is to separate either the bundled libsymspg or the python binding package into its separate PyPI package. Already the /python cmake project is buildable as standalone which would take the system's libsymspg, so the main project can just be converted to package the bundled library.

The issue is which pyproject.toml do we rename?

• spglib (libsymspg) + pyspglib (binding)
  • the user can pip install spglib and it works out-of-the box using the bundled
  • packagers need to switch to packaging pyspglib
  • probable surprises when uninstalling
• spglib (binding) + spglib-c (libsymspg)
  • the user may need to install spglib[library] to make sure it uses the bundled version
  • packagers are not affected
  • more explicit on the intent

This one could also be a very robust approach, but need consideration for which approach to take. Also CI tools need to be investigated, e.g. pytest would not be executable within python/pyproject.toml because the test files would not be in the sdist