Problem
Recent releases (e.g. 0.3.62/0.3.63) ship only an sdist (.tar.gz) on PyPI — no .whl. Earlier releases like 0.3.61 had a wheel. The repo has never contained any wheel build config (pyproject.toml, bdist_wheel, or a release workflow), so wheel-building depends entirely on the maintainer's local release command and silently drifts between releases.
Users without a wheel pay a slower install and must build from source. This causes problems with installing in the package in corporate environment where .gz and .zip extensions are blocked. This then breaks installations that rely on pyhocon.
Proposal
Add a minimal pyproject.toml declaring the build backend:
[build-system]
requires = ["setuptools>=61.0", "wheel"]
build-backend = "setuptools.build_meta"
setup.py stays unchanged — this just makes the standard command emit both artifacts:
python -m build # -> dist/*.tar.gz AND dist/*.whl
Verified locally: produces pyhocon-0.3.63.tar.gz and pyhocon-0.3.63-py3-none-any.whl.
Impact
No API or packaging-metadata changes.
Restores wheel distribution and makes it reproducible in-repo.
Problem
Recent releases (e.g. 0.3.62/0.3.63) ship only an sdist (.tar.gz) on PyPI — no .whl. Earlier releases like 0.3.61 had a wheel. The repo has never contained any wheel build config (pyproject.toml, bdist_wheel, or a release workflow), so wheel-building depends entirely on the maintainer's local release command and silently drifts between releases.
Users without a wheel pay a slower install and must build from source. This causes problems with installing in the package in corporate environment where
.gzand.zipextensions are blocked. This then breaks installations that rely on pyhocon.Proposal
Add a minimal pyproject.toml declaring the build backend:
setup.py stays unchanged — this just makes the standard command emit both artifacts:
Verified locally: produces pyhocon-0.3.63.tar.gz and pyhocon-0.3.63-py3-none-any.whl.
Impact
No API or packaging-metadata changes.
Restores wheel distribution and makes it reproducible in-repo.