Merge ppa-dev-tools:packaging-pypi into ppa-dev-tools:main
Status: | Merged |
---|---|
Merge reported by: | Bryce Harrington |
Merged at revision: | 03062a4271406b02133a320d290c45dc51e26a1c |
Proposed branch: | ppa-dev-tools:packaging-pypi |
Merge into: | ppa-dev-tools:main |
Diff against target: |
354 lines (+217/-14) (has conflicts) 10 files modified
INSTALL.md (+16/-1) Makefile (+40/-0) README.md (+22/-5) RELEASING.md (+79/-2) ppa/_version.py (+1/-1) pyproject.toml (+25/-2) requirements-dev.txt (+5/-0) setup.cfg (+2/-2) setup.py (+0/-1) tox.ini (+27/-0) Conflict in INSTALL.md |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Athos Ribeiro (community) | Approve | ||
Canonical Server Reporter | Pending | ||
Review via email: mp+429681@code.staging.launchpad.net |
Description of the change
This brings in a bunch of packaging-related work, mainly focusing on pypi and pulling ideas from Athos' lppa packaging. It's not a straight copy, though. The version number is passed to set-release-version via a VERSION environment variable instead of autoincrementing, in order to give me more explicit control over setting specific version numbers (I plan to jump from 0.5.0 or so, to 1.0.0, when things are ready). lppa updates version numbers to set them to end in .dev1 for periods when the codebase is under active development; that adds complexity to the Makefile and is probably not necessary this early on in development.
I've tested most of the targets in the Makefile. I know the RELEASING.md doc doesn't yet make use of them however I'll update the doc when I actually do the 0.2.0 release. I haven't been able to successfully test the check and coverage commands since there's still some busted test cases in the old code.
There was an error fetching revisions from git servers. Please try again in a few minutes. If the problem persists, contact Launchpad support.
Thanks, Bryce. LGTM
Some Makefile targets seem to still need some work/cleaning up, such as the devel one (I left an inline command there) depending on how we are going to manage the python packaging here. This can be done later though, when we decide on the packaging tooling stack.