-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update build mechanism #52
base: main
Are you sure you want to change the base?
Conversation
5c7f626
to
54e6eba
Compare
This enables building wheels using the latest setuptools and related tooling, while still distributing the man pages.
This both clarifies that it's static and better prepares this package for the future of python packaging. Notably this avoids importing the package as part of the build to get the description and version, which is already not supported in some cases.
54e6eba
to
f40877e
Compare
$ python3 setup.py bdist_wheel
/opt/homebrew/lib/python3.10/site-packages/setuptools/config/setupcfg.py:508: SetuptoolsDeprecationWarning: The namespace_packages parameter is deprecated, consider using implicit namespaces instead (PEP 420).
warnings.warn(msg, warning_class)
running bdist_wheel
...
copying sr/tools/inventory/inventory.py -> build/bdist.macosx-12-arm64/wheel/sr/tools/inventory
running install_data
running build_sphinx
error: invalid command 'build_sphinx' I think it's probably worth moving to PEP420 in this PR as well. (See error above) What am I missing to build sphinx here? Surely it should pull it in? Have you considered using other build tools? e.g (poetry or build). poetry is used for quite a lot of kit team projects these days. Build is used for april_vision, although we haven't fully evaluated how well it works in comparison to poetry yet. |
Huh, that was definitely working for me locally and seems to be working in CI. I had expected that it would be pulled in by what's in the In terms of alternatives, I had originally hoped this would be a simple minimal fix just to get the build working so CI would pass, rather than the larger change it turned into. I don't have strong feelings about moving to another build tool if there is one which will work for us here. In order to not break things we need one which supports dots in package names (poetry unfortunately no longer does, as we found out when trying to publish |
This moves to using more current Python packaging mechanisms which are now needed for recent versions of setuptools (which come by default with recent Python).
See individual commits for details.
I've tested manually that this preserves the support for
man sr-*
pages after install.TODO:
main
with the one produced here (for a setup where both worked, of course)