This solves 2 problems with the latest release (also described in this comment):
We depend on the packaging module, but didn't include it in the setup.py (because our testing and dev environments have tox installed and tox satisfies that requirement for itself, so we didn't notice).
Removing the file VERSION, and moving the static version information into the version.py module (just like in Juju) and use that information from there. The places that dynamically use that information (outside of the juju modules) are i) setup.py to get the version info into the build, ii) Makefile to use it in the release target iii) docs/config.py for building the docs. All of these spots are updated to use the info within the version.py.
QA Steps
We'll use the steps described in #1025. After pulling the branch in this PR;
Create a new virtual env:
python -m venv venv
Activate it:
source venv/bin/activate
Build pylibjuju at this spot:
python setup.py sdist
The sdist build will create a dist/juju-3.3.1.0.tar.gz, so install that:
Without the (1)st change in this PR, this command would result in:
ModuleNotFoundError: No module named 'packaging'
And without the (2)nd change, this command would error with
FileNotFoundError: [Errno 2] No such file or directory: '......./venv/lib/python3.10/site-packages/VERSION'
But with this change, we shouldn't see either (or any other) error. I.e., the command should succeed with no problems.
Notes & Discussion
Note that this changes the release process. In particular where we need to manually change the version information is moved into the version.py module (the release process document will be updated right before this PR is merged).
Moreover, we need to make a patch release (3.3.1.1) after this for these changes to take effect (i.e. for pylibjuju to be usable in the environments where it's installed as a dependency).
Description
This solves 2 problems with the latest release (also described in this comment):
packaging
module, but didn't include it in thesetup.py
(because our testing and dev environments have tox installed and tox satisfies that requirement for itself, so we didn't notice).This change fixes #1025, solving these issues by:
packaging
to the required modules.VERSION
, and moving the static version information into theversion.py
module (just like in Juju) and use that information from there. The places that dynamically use that information (outside of the juju modules) are i)setup.py
to get the version info into the build, ii)Makefile
to use it in the release target iii)docs/config.py
for building the docs. All of these spots are updated to use the info within theversion.py
.QA Steps
We'll use the steps described in #1025. After pulling the branch in this PR;
dist/juju-3.3.1.0.tar.gz
, so install that:Controller
.Without the (1)st change in this PR, this command would result in:
And without the (2)nd change, this command would error with
But with this change, we shouldn't see either (or any other) error. I.e., the command should succeed with no problems.
Notes & Discussion
Note that this changes the release process. In particular where we need to manually change the version information is moved into the
version.py
module (the release process document will be updated right before this PR is merged).Moreover, we need to make a patch release (
3.3.1.1
) after this for these changes to take effect (i.e. for pylibjuju to be usable in the environments where it's installed as a dependency).JUJU-5484