Move buildbackend from setuptools/pbr to hatchling

[jugmac00]

No description provided.

[jugmac00]

The tests are failing in CI as we do not install the project, which is required to generate the version info for hatchling.

This worked locally, and also for e.g. the fixtures project as there tox is used, which both handles the virtual environment creation and the installation.

Originally, I wanted to create a tox.ini file for this project to ease the test setup, but after the discussion in #10 (comment) I removed it to get things forward.

@jelmer and others, could you please advise what is the preferred solution here?

Would it be OK to add a tox.ini file, or should I create a virtualenv in the Makefile, and install the package afterwards?

[jelmer]

See testtools for an example of how this could work without installation.

[bigjools]

See testtools for an example of how this could work without installation.

The tests should be running in a venv where the package is installed. If installed with pip -e it also works for local testing.

[bigjools]

See testtools for an example of how this could work without installation.

The tests should be running in a venv where the package is installed. If installed with pip -e it also works for local testing.

hatch makes this trivial, FWIW.

[jugmac00]

@jelmer

See testtools for an example of how this could work without installation.

When I go to the testtools setup and run make I get the following error.

testtools on  master [$] via 🐍 v2.7.18 
❯ make
PYTHONPATH=/home/jugmac00/src/canonical/testtools python3 -m testtools.run testtools.tests.test_suite
Traceback (most recent call last):
  File "/home/jugmac00/src/canonical/testtools/testtools/__init__.py", line 114, in <module>
    from setuptools_scm import get_version
ModuleNotFoundError: No module named 'setuptools_scm'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/jugmac00/src/canonical/testtools/testtools/__init__.py", line 123, in <module>
    from ._version import __version__, version
ModuleNotFoundError: No module named 'testtools._version'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 185, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.8/runpy.py", line 111, in _get_module_details
    __import__(pkg_name)
  File "/home/jugmac00/src/canonical/testtools/testtools/__init__.py", line 127, in <module>
    raise RuntimeError(
RuntimeError: Testtools is not correctly installed. Please install it with pip.
make: *** [Makefile:7: check] Error 1

While this tells me what to do, it still means all the manual work for the contributor, i.e. create virtual environments for all supported Python versions, install the package there, and run the tests.

This seems a lot of effort compared to have a single configuration file, updated once a year when a new Python version gets released, but I am happy to go that route if this speeds up moving things forward.

[jugmac00]

@bigjools

The tests should be running in a venv where the package is installed.

That is the very issue - we could either do this manually in the Make file or at the cost of maintaining an additional configuration file for hatch or tox and updating it once a year when there is a new Python version coming out.

And while I am quite possible biased as I have been using tox for many years, and I am one of its maintainers, also for hatch you need to specify the Python versions, see https://hatch.pypa.io/latest/environment/#matrix, so at least from the features we need (ie build package, create venv, install package, run tests), both tools are pretty on par.

[jelmer]

@jelmer

See testtools for an example of how this could work without installation.

When I go to the testtools setup and run make I get the following error.

testtools on  master [$] via 🐍 v2.7.18 
❯ make
PYTHONPATH=/home/jugmac00/src/canonical/testtools python3 -m testtools.run testtools.tests.test_suite
Traceback (most recent call last):
  File "/home/jugmac00/src/canonical/testtools/testtools/__init__.py", line 114, in <module>
    from setuptools_scm import get_version
ModuleNotFoundError: No module named 'setuptools_scm'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/jugmac00/src/canonical/testtools/testtools/__init__.py", line 123, in <module>
    from ._version import __version__, version
ModuleNotFoundError: No module named 'testtools._version'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 185, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.8/runpy.py", line 111, in _get_module_details
    __import__(pkg_name)
  File "/home/jugmac00/src/canonical/testtools/testtools/__init__.py", line 127, in <module>
    raise RuntimeError(
RuntimeError: Testtools is not correctly installed. Please install it with pip.
make: *** [Makefile:7: check] Error 1

While this tells me what to do, it still means all the manual work for the contributor, i.e. create virtual environments for all supported Python versions, install the package there, and run the tests.

This seems a lot of effort compared to have a single configuration file, updated once a year when a new Python version gets released, but I am happy to go that route if this speeds up moving things forward.

Right, but this works fine today when you have setuptools-scm installed.

Note that I'm not using this for running tests (I run with my current python and rely on the CI to run tests against other Python versions), but rather for me to run breezy against testtools HEAD.