PEP 621: Migrate from setup.py to pyproject.toml

[cclauss]

https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html

• https://peps.python.org/pep-0621

Migrate setup.py to setup.cfg using setuptools-py2cfg. Then migrate setup.cfg to pyproject.toml using ini2toml to do the file conversion, and run pyproject-fmt and then validate-pyproject to validate the results.

uvx setuptools-py2cfg > setup.cfg
uvx 'ini2toml[full]' setup.cfg -o new_pyproject.toml
code *.toml  # Prepend the contents of new_pyproject.toml to the beginning of pyproject.toml
rm new_pyproject.toml
git rm setup.py
rm setup.cfg
uvx pyproject-fmt pyproject.toml
uvx 'validate-pyproject[all]' pyproject.toml
git grep setup
code sonar-project.properties README.rst
git commit -am"PEP 621: Migrate from setup.py to pyproject.toml"
git push

---

Related to:

• fix: Update Ruff target Python marker to minimum supported version 3.10 #521 because

If you're already using a pyproject.toml file, we recommend project.requires-python instead, as it's based on Python packaging standards, and will be respected by other tools. -- https://docs.astral.sh/ruff/settings/#target-version

[DhavalGojiya]

@cclauss
Since there is no [project] section in this package pyproject.toml file yet, I have kept the minimum version constraint inside ruff tool table:

[tool.ruff]
target-version = "py310"

I think it would be better if my previous PR is merged before yours.
CC: @acdha

[acdha]

I have learned not to trust the GitHub merge editor as it discarded most of my edit consolidating this block into the tool.ruff section below.

[cclauss]

I don't use GitHub Merge either. I just did not rebase against a current master. -- Fixed.

[DhavalGojiya]

Do we need setuptools as a base dependency for PySolr?

dependencies = ["requests>=2.32.5", "setuptools"]

It is used to build wheels from the source distribution, but according to: PEP-507 the build-backend requirements are
already installed in the isolated build environment during the build process.

[cclauss]

setuptools is sometimes required for Python >= 3.13 because it brings in some old distutils code.

• https://github.com/search?q=repo%3Adjango-haystack%2Fpysolr%20distutils

Given that we are whacking setup.py, perhaps we can also whack the dependency setuptools.

[DhavalGojiya]

setuptools is sometimes required for Python >= 3.13 because it brings in some old distutils code.

• https://github.com/search?q=repo%3Adjango-haystack%2Fpysolr%20distutils

But we no longer use the setup.py file, right? After this PR is merged?
So why is it still needed?

[cclauss]

Tons of advantages from moving away from setup.py!

[DhavalGojiya]

Tons of advantages from moving away from setup.py!

Just like this,
can we plan to move away from the setuptools build backend someday?
Hatchling is an excellent and modern build backend: https://hatch.pypa.io/latest/

[cclauss]

I would vote for uv instead of hatchling. Our tox runs are superslow for tests that only take 17 seconds!!

• Project Migration to UV #514

[DhavalGojiya]

I would vote for uv instead of hatchling. Our tox runs are superslow for tests that only take 17 seconds!!

• Project Migration to UV #514

I'm only referring to the Hatchling build backend.

[cclauss]

@DhavalGojiya Your review, please.

[DhavalGojiya]

We are using a dynamic version, but where are we getting this information from?

The build Metadata file:

Metadata-Version: 2.4
Name: pysolr
Version: 0.0.0
Summary: Lightweight Python client for Apache Solr

[cclauss]

Good catch!

Should we modify this logic to put the version here?

pysolr/pysolr.py

Lines 30 to 36 in ec2ff51

	__author__ = "Daniel Lindsley, Joseph Kocherhans, Jacob Kaplan-Moss, Thomas Rieder"
	__all__ = ["Solr"]
	try:
	__version__ = _get_version(__name__)
	except PackageNotFoundError:
	__version__ = "0.0.dev0"

[DhavalGojiya]

So we're using setuptools-scm, which dynamically determines the next release PyPi version based on the most recent GitHub tag.

The code in the pysolr.py file (lines 30-36) is completely fine - it simply reports which pysolr version is being used when we install pysolr as a dependency in a real project.
Basically, it allows the version to be identified programmatically, similar how pip show pysolr displays the version number.

Code:

Python 3.11.14 (main, Oct 31 2025, 22:57:10) [MSC v.1944 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pysolr
>>> pysolr.__version__  # under the hood `from importlib.metadata import version`
'3.11.0'
>>> from importlib.metadata import version
>>> version("pysolr")
'3.11.0'
>>> version("django")
'5.2.8'

[DhavalGojiya]

But can we drop setuptools-scm (dynamic versioning) completely and hard-code the version in pyproject.toml?

Like this:

[project]
name = "pysolr"
description = "Lightweight Python client for Apache Solr"
version = "3.11.0"

This looks very simple approach, especially since the pysolr package doesn't release new versions very often.
Whenever we need a new release for PyPi, we can just create a Bump x.y.z version PR or make a direct commit in master branch.

Any thoughts?
@acdha @cclauss

[DhavalGojiya]

We can remove this setuptools-scm safely from the build backend. Since we are not using dynamic versioning.

[DhavalGojiya]

@cclauss
1 - Why removed the whole build backend table? (since it Defaults fallback for most of front end build command?)
2 - It's still unclear that we should keep "setuptools" as base dependency of pysolr? As build backend requires are enough to built source distribution.