build(python): evaluate uv_build as the build backend #3887

Activity

1. mcosgriff

   added

   enhancementNew feature or requestNew feature or request

   triageMore information is neededMore information is needed

   on Sep 17, 2026
2. mcosgriff

   added the

   Feature

   issue type on Sep 17, 2026
3. crawlchat commented on Sep 17, 2026

   

   crawlchatbot

   on Sep 17, 2026 – with CrawlChat

   More actions

   This is a well-researched proposal and matches what's in the repo today. A few observations, plus a suggested path forward:

   Confirmed current state

   • pyproject.toml has exactly the setuptools bits described: [build-system] → setuptools.build_meta, [tool.setuptools] py-modules = ["openc3pycli"], and [tool.setuptools.packages.find] include = ["openc3*"].
   • setup.cfg is only the universal=0 flag, as you said.
   • MANIFEST.in only adds LICENSE.md and recursive-include examples *.
   • openc3pycli.py deliberately lives outside the openc3 package — its docstring explains this is intentional, so that OPENC3_NO_STORE can be set before openc3/__init__.py (and therefore openc3.environment) is imported. That constraint matters for your migration decision.

   On the openc3pycli decision

   Given that comment, moving openc3pycli.py under openc3/ would need care — if openc3.pycli (or wherever it lands) is imported, Python will still execute openc3/__init__.py first as part of package initialization, which is exactly the ordering problem the current top-level placement avoids.

   The "make it a package" option (openc3pycli/__init__.py at the top level, sibling to openc3/) preserves the existing import-order guarantee without changing behavior, and is likely the lower-risk choice. It only changes packaging layout (single-file module → package with one __init__.py), not where it lives relative to openc3/__init__.py.

   If moving under openc3/ is still desired, the OPENC3_NO_STORE guard would need to move somewhere that runs before openc3/__init__.py's side effects — that's a separate design question worth its own discussion, not something to fold into this ticket.

   Not verified (tool limit reached)

   I wasn't able to read .github/workflows/release.yml in this pass to confirm the exact setup-python / python -m build block, so I can't give you a verified diff for that file right now. The described change (drop setup-python, replace python -m build with uv build) is consistent with how the rest of the workflows use uv, but please have a maintainer confirm the exact YAML before merging.

   Suggested sequencing, matching your writeup:

   1. Land the openc3pycli packaging change (package-style, keeping it top-level) as its own PR.
   2. Do the real sdist diff for examples/** under source-include vs. MANIFEST.in's recursive-include examples * — don't skip this, since sdist contents affect what installs from source distributions.
   3. Switch pyproject.toml to uv_build, delete setup.cfg, delete MANIFEST.in, update release.yml.

   Given the level of detail already here, I'd suggest opening the PR with these steps — it looks like solid, self-contained work that an engineer can review quickly.
4. mcosgriff

   self-assigned this

   on Sep 17, 2026
5. mcosgriff

   added

   python:uvPull requests that update python:uv codePull requests that update python:uv code

   on Sep 17, 2026