Chore: Migrate to pyproject.toml

[ftnext]

supported by GPT 5.4

---

Packaging migration notes

This branch started as a packaging migration from the legacy setup.py / setup.cfg layout to a pyproject.toml-based configuration, and the later commits in this review cycle focused on preserving compatibility and avoiding migration regressions.

Initial migration on this branch

The initial migration work on this branch already did the following:

• Moved packaging metadata from setup.py / setup.cfg into pyproject.toml.
• Declared project metadata in PEP 621 format.
• Moved extras into project.optional-dependencies.
• Declared the console script entry point in project.scripts.
• Moved setuptools configuration into pyproject.toml.
• Removed the old setup.cfg packaging configuration.
• Initially removed setup.py as part of the migration.

Review-driven follow-up decisions

During review, the following decisions were made and applied in order to keep the migration safe and compatible:

• Switched dynamic version loading from attr to file.

  • tool.setuptools.dynamic.version now reads from speech_recognition/version.txt.
  • This avoids importing speech_recognition at build time.

• Kept __version__ as a runtime attribute, but did not expand dynamic metadata usage to other dunder attributes.

  • __version__ remains commonly useful at runtime.
  • __author__ and __license__ are kept as compatibility-oriented module attributes for now.

• Added speech_recognition/version.txt as package data.

  • This keeps build-time metadata generation and runtime version access aligned.

• Changed project.license to license = { file = "LICENSE.txt" }.[1]

  • This was chosen as the more conservative compatibility option during migration.

• Updated the end-user installation command in README.rst.

  • Replaced python setup.py install with python -m pip install ..

• Restored a minimal setup.py compatibility shim:

  • from setuptools import setup; setup()
  • This preserves backward compatibility for the legacy python setup.py bdist_wheel path while the repository still contains older release tooling and documentation references.

• Disabled implicit namespace package discovery.

  • Added namespaces = false under tool.setuptools.packages.find.
  • This keeps package discovery closer to the previous find_packages() behavior and avoids unintentionally shipping unrelated directories.

• Relaxed the build requirement from setuptools>=68 to setuptools>=61.

  • >=61 is sufficient as an early PEP 621-compatible baseline and avoids an unnecessarily strict toolchain floor.

• Dropped the explicit wheel build requirement.

  • setuptools.build_meta does not need wheel listed explicitly here.
  • Removing it avoids an unnecessary extra build dependency during isolated builds.

• Removed redundant include-package-data = true.

  • With pyproject.toml, this setting is already the default in setuptools.

Decisions intentionally deferred

Some concerns were discussed but intentionally left out of this PR:

• Offline pip install . behavior under PEP 517 build isolation is not fully addressed here.

  • Lowering the setuptools floor and removing the explicit wheel requirement help reduce unnecessary strictness, but they do not eliminate the broader isolated-build behavior introduced by pyproject.toml builds.
  • Handling this properly would require a separate decision about supported installation workflows, documentation, or packaging policy.

• The release workflow is not fully modernized in this PR.

  • In practice, releases are currently handled via make distribute and make publish.
  • However, because the repository still contains legacy release tooling/documentation, this PR keeps a minimal setup.py shim for compatibility instead of trying to clean up the entire release flow at once.

• The runtime __version__ implementation is not being redesigned further in this PR.

  • The goal here is to keep the build-time migration safe and minimally invasive.
  • Any broader reconsideration of runtime metadata access can be handled separately if needed.

Planned follow-ups

The following work is better handled separately from this migration PR:

• Update release documentation to describe the current make distribute / make publish workflow.
• Revisit whether make-release.sh should be removed or rewritten around modern PEP 517 build commands.
• Decide whether offline/local source installs should be documented explicitly (for example, --no-build-isolation) or handled with a broader packaging policy change.
• Revisit whether runtime metadata access should remain as-is or move to a different implementation.

---

[1]: Also fixes this:

Please consider removing the following classifiers in favor of a SPDX license expression:

License :: OSI Approved :: BSD License

See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license for details.

[Copilot]

Pull request overview

Migrates the project’s packaging configuration from setup.py/setup.cfg to a PEP 621-style pyproject.toml, consolidating build metadata, dependencies, and extras into a single modern packaging file.

Changes:

• Removed legacy setup.py-based packaging configuration.
• Removed setup.cfg extras definition in favor of pyproject.toml.
• Added pyproject.toml with project metadata, dependencies/extras, console script entry point, and setuptools configuration.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
setup.py	Removed setuptools-based packaging script in favor of pyproject.toml.
setup.cfg	Removed extras definitions migrated to pyproject.toml.
pyproject.toml	Added build-system + PEP 621 project metadata, dependencies, optional-dependencies, and setuptools configuration.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.