search

labscript-suite / labscript

The 𝗹𝗮𝗯𝘀𝗰𝗿𝗶𝗽𝘁 library provides a translation from expressive Python code to low-level hardware instructions.
http://labscriptsuite.org
BSD 2-Clause "Simplified" License
9 stars 51 forks source link

Add setuptools_scm build arguments to pyproject.toml #110

Closed dihm closed 4 months ago

dihm commented 8 months ago

This provides further fixes to how we use setuptools_scm as noted in comments on #106.

This should fix the random build issues (of which I still cannot replicate the successful build from two weeks ago). Basic premise is that setuptools_scm will use whatever is in the pyproject.toml to determine the version scheme if it is getting version by inspecting files (ie not installing). It will use setup.py to override the pyproject.toml settings when installing, and it will use __version__.py to override everything when importing the package.

There are a few minor choices we could make here beyond what is currently in the PR:

  1. The os.getenv calls in setup.py and __version__.py are no longer required. I'm not sure they are even needed with this change. Should we just remove them?
  2. setuptools_scm is a sort of runtime dependency of all the packages right now. If you have a .git folder, it will fail if setuptools_scm isn't installed. I'm inclined to wrap that in a try/except so it just falls back to importlib_metadata instead and keep this off the official dependency list. That said, we could also just enforce it as a dependency for everyone, even it they are installing from pip.
  3. We could use this as an opportunity to port over setup.cfg to the pyproject.toml and only have one metadata file.
  4. It may not be a bad idea to drop node-and-date from the local scheme when installing, (particularly for editable mode). Then we wouldn't need the overrides in setup.py which I suspect might be fragile going forward. It also makes the package versions under conda list a bit less noisy (so only have v3.3.0.devN instead of v3.3.0.devN+SHA.date) and doesn't remove much information since the node/date info in an editable install is all but worthless anyway for how quickly it stales. Having that info at import time where it can update automatically is the only place I see it having real value.

These changes, assuming they are sufficient, will need to be ported to all the repos. So @philipstarkey, any thoughts before I get cracking on that?

dihm commented 8 months ago

@philipstarkey I've gone ahead and made commits that implement all of the above suggestions. Happy to back out any that are beyond the pail.

dihm commented 4 months ago

Going to go ahead with these changes since nothing heard. Will start working through the other projects to update to this standard.