Bump version number #1039
Assignees
Labels
Comments
|
Huh, thanks. I didn't even know that this existed. I'm not sure I love the way version.py handles it (I'd rather not be running git on import!) so maybe we can reconsider that at the same time. |
benhoyt
pushed a commit
that referenced
this issue
Jan 16, 2024
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
|
#1068 fixed this also. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
operator/ops/version.py
Line 25 in a55a07a
We wanted to have a sane default for ops but mostly rely on the git tag. However, 1.0 is now pretty old relative to current ops, so we should probably bump this.
The text was updated successfully, but these errors were encountered: