-
Notifications
You must be signed in to change notification settings - Fork 119
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
Migrate to pyproject.toml #893
Comments
We're leaning towards not doing this at present, but Tony's going to look into it further and make an evaluation. |
Have been away from the project for a while, let me know about the result of the evaluation. Happy to help with a PR, if needed. |
setup.py currently replaces |
Possibly useful reading when we start on this: https://til.simonwillison.net/python/pyproject |
Simon also recently linked to this post on moving off setup.py. |
Modernisation of distribution and build tooling: this PR attempts to bring `ops` up-to-date with current packaging best practice. The particular focus is on moving away from `setup.py` and using `pyproject.toml` as the source of truth for configuration, with a [PEP 517](https://peps.python.org/pep-0517/)/[PEP 518] (https://peps.python.org/pep-0518/) compliant build system. ### Metadata The project metadata has moved from `setup.py` to [pyproject.toml] (pyproject.toml). This is generally a simple move, except: * The author name and email has been updated from Charmcraft (likely a bad copy-and-paste) to Charm Tech. * pyproject.toml allows for more project URLs, so "Homepage", "Repository", "Issues", "Documentation", and "Changelog" have been included. A few `test_infra` tests were removed as a result, as they were previously validating custom code in `setup.py` and now that functionality is provided by the build backend (for example, including the contents of the README). ### Source distribution changes I've added a MANIFEST.in file to more explicitly define which files are included. There are more files than previously, however: * CHANGES.md * CODE_OF_CONDUCT.md (this is more for interacting, so could be excluded, but it's linked from the README so seems wrong to not be included) * HACKING.md * test/bin, test/charms, test/smoke * test/pebble_cli.py * tox.ini ### Dependency management The list of dependencies has moved from `setup.py` and `requirements.txt` to `pyproject.toml`. We no longer keep two lists of the dependencies in sync, so a `test_infra` test can be removed. The dev requirements have been split out into groups for each tox environment, and are located in `tox.ini`. The documentation dependencies have moved from `docs/requirements.in` to `pyproject.toml` in an extra-dependencies section. The `docs/requirements.txt` file can be generated using `pip-compile`, which removes the need for the (undocumented) `docs/update_requirements.sh` script. `tox -e docs` will also run the `pip-compile` step, so normally contributors should not need to install and run `pip-compile` themselves, just do the normal steps of running `tox -e docs` to locally inspect the docs, and commit the updated lock file if there are changes. If anyone is relying on `requirements.txt` or `requirements-dev.txt` to exist (e.g. as we do with the CI that tests against key charms) that will break, but it seems unlikely that anyone is downstream doing that. ### CI changes * We now verify that building and (more importantly) installing works on a matrix of macOS and Ubuntu in Pythons 3.8-3.12. This was previously only Ubuntu and only 3.11 (until recently, whatever Python version the GitHub Action defaulted to). It's unlikely that installing will break for macOS only or for specific Python versions, but possible. * We now use `build` as the build frontend (`setuptools` remains the build backend) for building distributions to publish to PyPI (ideally [we have access to test.pypi.org] (pypi/support#3349) in order to verify that this works correctly before merging). Also moves back to using the default GitHub Action Python version, since we are no longer impacted by the `distutils` removal. * Similarly, uses `build` as the build frontend for validating that building works correctly. ### Doc changes * Expanded HACKING.md to include more detailed information about the tools that we use for development. The "Dependencies" section was also a sub-section of the "Documentation" section, which I think was an error, so promote it to top-level. ## Version In `ops` 2.8, `ops.__version__` is: * `<tag>-<#commits>-g<hex>[-dirty]` (or just `<tag>` if there are no local commits) if there is a `.git` folder and `git describe --tags --dirty` runs (note that this means that importing `ops` from a Git clone will always spawn a `git` subprocess) * `1.0.dev0+unknown` if running from a non-built source (e.g. a GitHub tarball). * `<tag>` if running from a built source (e.g. from PyPI), or `<tag>-<#commits>-g<hex>[-dirty]` if running from a 'dirty' built source (e.g. a local `python setup.py sdist`) (note that this is from a static file generated in the build process and does not spawn any subprocess) This PR replaces that with a much simpler system: * `ops/version.py` has a static, manually managed, `version` string (in this module for backwards compatibility). * Prior to publishing a release, the release manager gets a PR merged that sets that string to the appropriate value. * Immediately after publishing a release, the release manager gets a PR merged that sets that string to the expected next release, with `.dev0` appended. ### Further changes We expect to also change from using pyflakes (and extensions), isort, and (potentially autopep8) to using ruff. Either as part of that change, or as a further follow-up, I intend to propose an (optional) pre-commit configuration that would optionally automatic some of the tooling (both the formatting and linting, and also the pip-tools management introduced in this PR). Fixes #893, #1039
Operator codebase contains a
pyproject.toml
and asetup.py
file at present. Modernpyproject.toml
specifications allow us to buildpip
packages without needing to define a setup module for invokingsetuptools
.Read More -
The text was updated successfully, but these errors were encountered: