Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.30%. Comparing base (705beb7) to head (cf20b8c).
Report is 31 commits behind head on develop.

@@           Coverage Diff            @@
##           develop     #520   +/-   ##
========================================
  Coverage    73.30%   73.30%           
========================================
  Files           26       26           
  Lines         8068     8068           
  Branches      1691     1692    +1     
========================================
  Hits          5914     5914           
  Misses        1627     1627           
  Partials       527      527           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Great, it seems we need to resolve #466 for this 😮‍💨

Current status:

• The macos issue has me completely stumped. I would need someone on a mac device to try and build the wheel and share it with me to see if there is some inconsistencies. Either building with python -m build or with cibuildwheel if possible
• The windows issue is a design issue in that windows does not have rpath equivalent. Instead all .dll files must be in the same runtime directory, but CMake convention puts it at bin which makes it incompatible. On the other hand this clashes with the import ... path. Need some more help from a windows user to figure out how are find_package working in those environments particularly when each package has a different ROOT.
• I had to alter the documentation because it was failing at relative imports evaluation. This should be better fixed in doc: Use autodoc #466. @lan496 can you review c8d58da and the current status of the generated docs?

can you review c8d58da and the current status of the generated docs?

The commit looks good to me.

can you review c8d58da and the current status of the generated docs?

The commit looks good to me.

I was rather referring to the generated documentation, e.g.:

• https://spglib--520.org.readthedocs.build/en/520/api/python-api/index.html
• https://spglib--520.org.readthedocs.build/en/520/python-interface.html#api-summary

Oh, I didn't find a successfully built RtD for this PR.

• From some point, the extra "None" appears in the docs.
  

• import spglib disappears in python-interface.md
  

import spglib disappears in python-interface.md

Oh weird that must have sneaked in when we introduced doctest.

From some point, the extra "None" appears in the docs.

Wasn't that some weird quirk of autodoc2? It seems to be present in develop as well. That seems to go away with autodoc, so how about moving that forward?

Ok, managed to fix the windows and macos issues. But this PR is blocked by an upstream issue: scikit-build/scikit-build-core#860 basically if we run pip install . twice, it might not bundle spglib C library the second time

Final blocker: scikit-build/scikit-build-core#880

Ok, I've managed to figure out a workaround for the pip isolation failure. This PR is ready for review, but I don't know if we want to add it to 2.6.0, it has quite a big change in the build process.

Could you manually check with

$ pip install "spglib@git+https://github.com/LecrisUT/spglib@fix/510"

Particularly test that it imports correctly every time you re-run pip install, and that it works in both normal and editable mode.

You should also have a full set of wheel artifacts here

Awesome! I've checked both normal and editable installs, and they work.