group.so and stk.so are installed outside of the sherpa namespace about sherpa HOT 6 OPEN

This is a known issue and derives directly from CIAO, where these modules are built outside of Sherpa and installed in the global namespace for all the CIAO components to use.

Sherpa should be a good Python citizen and should avoid installing these modules in the global namespace, so I will take this as a RFE on both the build process (avoid installing group and stk in the global namespace) and the code (Sherpa should try to import these modules from the sherpa namespace and fall back to the global namespace). Not sure what the priority for this change will be, though.

In my tests, pip correctly identifies those modules as part of the Sherpa installation and correctly removes them during a pip uninstall sherpa: in my experience this is not always true, and I don't think I could find any patterns to explain why sometimes that does not happen.

from sherpa.

It would be great if this could be fixed for the next Sherpa release (see #75 (comment))

from sherpa.

For reference (as part of the "we need to revamp the sherpa build project") I need to read https://discuss.python.org/t/building-extension-modules-the-2020-way/5950/33 and related

from sherpa.

I noted that - at least in the one case I'm currently looking at - I get
error: [Errno 2] No such file or directory: '/Users/guenther/code/sherpa/build/lib/python3.11/site-packages/stk.so' when I install as editable for development with pip install -e ., but not when I install normally pip install .

That's (a) good because I can work around out (it's a little more cumbersome to have to run the install every every change in a Python file, but possible) and (b) because it might give a hint (thought I don't quite know which one) what causes this.

from sherpa.

I wonder - and this is a completely random thought - whether we need

pip install -e . --no-build-isolation

from sherpa.

A quick build later suggests that may not be much of a help ....

from sherpa.