📄 Documentation for this branch is available at: https://ncar.github.io/musica/branch/650-update-python-packaging/

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.24%. Comparing base (2f59d9b) to head (b5d5c21).

@@           Coverage Diff           @@
##             main     #662   +/-   ##
=======================================
  Coverage   78.24%   78.24%           
=======================================
  Files          54       54           
  Lines        6857     6857           
=======================================
  Hits         5365     5365           
  Misses       1492     1492           

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

@boulderdaze do you have a preference for folder names?

Our current structure with this PR is this

Top level has src, javascript c++ code is in javascript/src, but python is python/bindings.

:: tree -L1 src javascript python 
src
├── carma
├── CMakeLists.txt
├── component_versions.cpp
├── micm
├── packaging
├── test
├── tuvx
├── util.cpp
└── version.cpp.in
javascript
├── CMakeLists.txt
└── src
python
├── bindings
├── CMakeLists.txt
├── musica
├── test
└── tools

@boulderdaze do you have a preference for folder names?

Our current structure with this PR is this

Top level has src, javascript c++ code is in javascript/src, but python is python/bindings.

:: tree -L1 src javascript python 
src
├── carma
├── CMakeLists.txt
├── component_versions.cpp
├── micm
├── packaging
├── test
├── tuvx
├── util.cpp
└── version.cpp.in
javascript
├── CMakeLists.txt
└── src
python
├── bindings
├── CMakeLists.txt
├── musica
├── test
└── tools

The code in the bindings directory does binding work, so I think it’s more explicit and clear to keep it named that way. It reflects what the code does.
I’m not entirely sure I understand your question. Are you suggesting using python/src/bindings, or changing bindings to src? If it’s the first option, that’s fine with me. But if it’s the second, I think we should keep the bindings name unless we plan to rename all the files to include binding.

@boulderdaze do you have a preference for folder names?
Our current structure with this PR is this
Top level has src, javascript c++ code is in javascript/src, but python is python/bindings.

:: tree -L1 src javascript python 
src
├── carma
├── CMakeLists.txt
├── component_versions.cpp
├── micm
├── packaging
├── test
├── tuvx
├── util.cpp
└── version.cpp.in
javascript
├── CMakeLists.txt
└── src
python
├── bindings
├── CMakeLists.txt
├── musica
├── test
└── tools

The code in the bindings directory does binding work, so I think it’s more explicit and clear to keep it named that way. It reflects what the code does. I’m not entirely sure I understand your question. Are you suggesting using python/src/bindings, or changing bindings to src? If it’s the first option, that’s fine with me. But if it’s the second, I think we should keep the bindings name unless we plan to rename all the files to include binding.

It would be to rename bindings to src. I agree that the name bindings is clear, it's just different to what we have in javascript. We can have the A&M students rename that folder to bindings to make it clear