Update build process to current standards #84

DimitriPapadopoulos · 2025-08-03T17:00:41Z

Fixes #83.

setup.py → pyproject.toml
use setuptools_scm to retrieve version from Git tags at build time
use importlib.metadata.version to retrieve version at run time
setuptools_scm pulls all files under version control, adapt MANIFEST.in
update years of copyright under doc

I haven't updated the documentation yet, still based on setup.py. I'll do that once the current changes have been discussed/accepted.

* setup.py → pyproject.toml * use setuptools_scm to retrieve version from Git tags at build time * use importlib.metadata.version to retrieve version at run time * setuptools_scm pulls all files under version control, adapt MANIFEST.in * update years of copyright under doc

DimitriPapadopoulos · 2025-08-10T16:56:14Z

The CI error is:

 ImportError: Error importing plugin "pytest_dependency": No module named 'pytest_dependency'

It's as if pytest_dependecy was not installed when running tests. Will have to look into it.

RKrahl

Many thanks for your effort. But I'm sorry, I'm not happy with the overall dircetion and inclined not to accept the change.

use setuptools_scm to retrieve version from Git tags at build time

Please note that I dropped setuptools_scm in favour of git-props in #75. I don't think, I will revert that decision.

use importlib.metadata.version to retrieve version at run time

Please see my comment on that change in doc/src/conf.py.

setuptools_scm pulls all files under version control, adapt MANIFEST.in

Yeah and that is plain silly and only one of several reasons to drop setuptools_scm. A source distribution is the collection of files needed to install the package from the sources. That is not to be confused with a snapshot of the source repository. Yes, I know that you fix that with the several exclude clauses in MANIFEST.in, but I consider it just stupid if I have to list the files that I don't want to include.

setup.py → pyproject.toml

Of course I know that the official docs recommend that. But to be honest, I see several practical disadvantages in that approach and fail to see any real benefit.

update years of copyright under doc

Obviuosly, this is sensible to do. It will certainly be done in time bevor the next release.

RKrahl · 2025-08-10T16:14:07Z

pyproject.toml

+Homepage = "https://github.com/RKrahl/pytest-dependency"
+Documentation = "https://pytest-dependency.readthedocs.io"
+Source = "https://github.com/RKrahl/pytest-dependency.git"
+Download = "https://github.com/RKrahl/pytest-dependency/releases/"


The current setup.py sets the Download URL to "https://github.com/RKrahl/pytest-dependency/releases/%s/" % release for a very good reason: as you can see see on the PyPI package page for release 0.6.0, it directly points to https://github.com/RKrahl/pytest-dependency/releases/0.6.0/, not to https://github.com/RKrahl/pytest-dependency/releases/ or https://github.com/RKrahl/pytest-dependency/releases/tag/latest/

This has the advantage that this link always matches the version you are looking at and remains valid also if I publish new releases.

Yes, but it requires to execute code at installation time, which is to be avoided.

RKrahl · 2025-08-10T16:37:27Z

doc/src/conf.py

 author = 'Rolf Krahl'

 # The full version, including alpha/beta/rc tags
-release = pytest_dependency.__version__
+try:
+    release = version(project)


This will discover the version of the currently installed version. Not the version of the package that the current document build is running from.

We can write to pytest_dependency.__version__, no problem, but need to make sure pytest_dependency.__version__ is written before building the documentation.

RKrahl · 2025-08-10T16:40:13Z

MANIFEST.in

-include tests/pytest.ini
-include tests/test_*.py
+exclude Makefile
+exclude python-pytest-dependency.spec


I believe it is simply weird if I need to list all the files that I don't want to include.

Indeed, setuptools_scm performs two tasks at the same time, without any clear way to disable one of them:

retrieve version from Git tags,

rewrite the list of files to be included in distributions based on the contents of version control system.

I'm not fond of that either.

RKrahl · 2025-08-10T17:19:35Z

pyproject.toml

@@ -0,0 +1,34 @@
+[build-system]
+requires = ["setuptools>=64", "setuptools-scm"] 


Installing a plain Python package is such a trivial task that I don't like to to add extra requirements just for this. setuptools (without version constraint) is an exception that I'm willing to take, but I prefer not to go beyond that.

Requiring a (not so much) recent setuptools at build time is not a strong requirement. Besides, even at installation time, setuptools needs to be current. From the Python Packaging User Guide:

Ensure pip, setuptools, and wheel are up to date

While pip alone is sufficient to install from pre-built binary archives, up to date copies of the setuptools and wheel projects are useful to ensure you can also install from source archives:

I can understand why you want to remove setuptools_scm.

All Python packages are moving to recent versions of setuptools, that's the direction taken by the whole community. I don't understand arguments such as "I prefer not to".

pyproject.toml

RKrahl · 2025-08-10T17:33:09Z

pyproject.toml

+  "License :: OSI Approved :: Apache Software License",
+  "Operating System :: OS Independent",
+  "Programming Language :: Python",
+  "Programming Language :: Python :: 3",


I prefer to explicitly list the Python version the respective release supports. It makes it easier when you browse PyPI and to answer questions like "what was the last release that did support Python X.Y?"

And, before you ask: yes before making any release I do test with all officially supported Python versions. I'm not relying on the GitHub workflow alone for that.

That's what requires-python = ">=3.4" is for. It does appear in PyPI. Why duplicate the information?

RKrahl · 2025-08-10T17:49:23Z

It's as if pytest_dependecy was not installed when running tests. Will have to look into it.

Note that in the current setup, the test suite imports pytest_dependecy from the build directory in the current working directory. They do not require to install the package to test it.

DimitriPapadopoulos · 2025-08-10T18:12:19Z

Of course I know that the official docs recommend that. But to be honest, I see several practical disadvantages in that approach and fail to see any real benefit.

Sure, but you cannot navigate against the direction taken by the whole community for ever. And perhaps the community as a whole knows better... For example, from a security point of view, an installation process based on an executable Python file instead of a declarative configuration file is not great. The declarative configuration file is not a silver bullet, of course, but it's a step in the right direction.

Why you shouldn't invoke setup.py directly

DimitriPapadopoulos · 2025-08-10T18:20:51Z

Please note that I dropped setuptools_scm in favour of git-props in #75. I don't think, I will revert that decision.

By the way, current git-props is documented to require Python 3.6:
https://github.com/RKrahl/git-props?#system-requirements
Do you pull an older version to run the build process with Python 3.4?

In any case, I understand why you want to stick with git-props. That's an obstacle indeed, it might be hard to use from a declarative config file.

DimitriPapadopoulos · 2025-08-10T18:23:38Z

Note that in the current setup, the test suite imports pytest_dependecy from the build directory in the current working directory. They do not require to install the package to test it.

Yes, this problem surfaces very often when updating the build system of a package. I must admit I don't know what the recommended / best / official ways to handle that are. I need more reading. Unless you have clues?

DimitriPapadopoulos force-pushed the setuptools branch 7 times, most recently from 4e5fd32 to 2cd94b3 Compare August 10, 2025 14:37

DimitriPapadopoulos force-pushed the setuptools branch from 2cd94b3 to 8b80418 Compare August 10, 2025 16:50

DimitriPapadopoulos marked this pull request as draft August 10, 2025 16:56

RKrahl requested changes Aug 10, 2025

View reviewed changes

pytest>=3.7.0

dc42fbe

		@@ -0,0 +1,34 @@
		[build-system]
		requires = ["setuptools>=64", "setuptools-scm"]

Update build process to current standards #84

Are you sure you want to change the base?

Update build process to current standards #84

Uh oh!

Conversation

DimitriPapadopoulos commented Aug 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DimitriPapadopoulos commented Aug 10, 2025

Uh oh!

RKrahl left a comment

Choose a reason for hiding this comment

Uh oh!

RKrahl Aug 10, 2025

Choose a reason for hiding this comment

Uh oh!

DimitriPapadopoulos Aug 10, 2025

Choose a reason for hiding this comment

Uh oh!

RKrahl Aug 10, 2025

Choose a reason for hiding this comment

Uh oh!

DimitriPapadopoulos Aug 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RKrahl Aug 10, 2025

Choose a reason for hiding this comment

Uh oh!

DimitriPapadopoulos Aug 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RKrahl Aug 10, 2025

Choose a reason for hiding this comment

Uh oh!

DimitriPapadopoulos Aug 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Ensure pip, setuptools, and wheel are up to date

Uh oh!

Uh oh!

RKrahl Aug 10, 2025

Choose a reason for hiding this comment

Uh oh!

DimitriPapadopoulos Aug 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RKrahl commented Aug 10, 2025

Uh oh!

DimitriPapadopoulos commented Aug 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DimitriPapadopoulos commented Aug 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DimitriPapadopoulos commented Aug 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

DimitriPapadopoulos commented Aug 3, 2025 •

edited

Loading

DimitriPapadopoulos Aug 10, 2025 •

edited

Loading

DimitriPapadopoulos Aug 10, 2025 •

edited

Loading

DimitriPapadopoulos Aug 10, 2025 •

edited

Loading

DimitriPapadopoulos Aug 10, 2025 •

edited

Loading

DimitriPapadopoulos commented Aug 10, 2025 •

edited

Loading

DimitriPapadopoulos commented Aug 10, 2025 •

edited

Loading

DimitriPapadopoulos commented Aug 10, 2025 •

edited

Loading