PEP 541 Request: ops on TEST pypi #3349
Labels
PEP 541
Package name support requests
Comments
This was referenced Nov 15, 2023
|
Hi! Let me know if there's anything missing here that would block processing this, or if there's anything I can do on my end to make things simpler. Thanks! |
tonyandrewmeyer
changed the title
benhoyt
pushed a commit
to canonical/operator
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
tonyandrewmeyer
added a commit
to canonical/operator
that referenced
this issue
Jun 26, 2024
This PR adds [artefact attestation](https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/) to the ops builds. Essentially: users are able to verify that the wheel and source dist tarball produced by the build script were actually generated by the workflow in this repo (and not, for example, uploaded by someone else that got access to the PyPI account). The `test-publish` workflow is also updated to use the `build` backend, which was missed when the main script was migrated. Annoyingly, [we are still waiting for access to the operator package on test.pypi.org](pypi/support#3349).
amandahla
pushed a commit
to amandahla/operator
that referenced
this issue
Jun 26, 2024
This PR adds [artefact attestation](https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/) to the ops builds. Essentially: users are able to verify that the wheel and source dist tarball produced by the build script were actually generated by the workflow in this repo (and not, for example, uploaded by someone else that got access to the PyPI account). The `test-publish` workflow is also updated to use the `build` backend, which was missed when the main script was migrated. Annoyingly, [we are still waiting for access to the operator package on test.pypi.org](pypi/support#3349).
tonyandrewmeyer
added a commit
to tonyandrewmeyer/operator
that referenced
this issue
Jun 26, 2024
This PR adds [artefact attestation](https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/) to the ops builds. Essentially: users are able to verify that the wheel and source dist tarball produced by the build script were actually generated by the workflow in this repo (and not, for example, uploaded by someone else that got access to the PyPI account). The `test-publish` workflow is also updated to use the `build` backend, which was missed when the main script was migrated. Annoyingly, [we are still waiting for access to the operator package on test.pypi.org](pypi/support#3349).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Project to be claimed
ops: https://test.pypi.org/project/opsYour PyPI username
tonyandrewmeyer: https://test.pypi.org/user/tonyandrewmeyerReasons for the request
I'm one of the maintainers of the
opspackage. We have ownership of pypi.org/project/ops, but someone else has test.pypi.org/project/ops. The test account isn't being used for a different package - it's just a quite old version of our ops package.I'd like to start using test.pypi.org to test our publishing processes, and it makes sense to me that we would have the same project name as on the real pypi.org (and I'd also like to get that old
opsversion off test.pypi.org).I can't find any contact details for the user that's listed as the owner of the test.pypi.org to reach out to them directly. As far as we are aware they have never been involved with the
opsproject (or otherwise have worked for Canonical, who own the project).Maintenance or replacement?
Maintenance
Source code repositories URLs
https://github.com/canonical/operator
(Same in both cases, the one on test.pypi.org now is just an old version).
Contact and additional research
As noted above, I have not been able to find any contact details for the current user. You can see that I am a maintainer for the same project on pypi.org, or contact us via the official project page.
Code of Conduct
The text was updated successfully, but these errors were encountered: