Backwards compatible packaging

[bwhmather]

This PR switches to a hybrid pyproject.toml/setup.py/setup.cfg that should work with versions of setuptools at least as far back as 39.0 (required for CentOS 7), and probably older. It retains the [build-system] section in pyproject.toml and so should now also be useable by newer dependency management tools that won't support setup.py.

As part of this had to introduce a MANIFEST.in, and therefore have taken the effort of excluding anything we don't need from the sdist.

[github-actions[bot]]

Pull Request Test Coverage Report for Build 5368595669

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 98.242%

---

Totals
Change from base Build 5340571177:	0.0%
Covered Lines:	1285
Relevant Lines:	1308

---

💛 - Coveralls

[cgahr]

Tbh, I don't really like this.

• do we really need to support setuptools 39.0 (which was releasen March 2017!)?
• afaik, the new standard to define packages is pyproject.toml, now we go back to setup.cfg?

[bwhmather]

You might be right with bundling setup.py. Afaict, PEP-517 support was added to setuptools in version 36.6.0. Haven't been able to find the release for pip but I would imagine that it would have been around the same time.

I think it's definitely too soon to have the project metadata in pyproject.toml though. It's not supported by the system setuptools in any version of centos or LTS ubuntu. This is very much the sort of tool which people want to install globally or in their home directory, and removing setup.cfg would prevent that in a large proportion of reasonable setups.

I think the really important bit from your pyproject.toml change is the introduction of [build-system]. This allows dependency managers to avoid guessing at what will need to be installed before having to run setup.py. It is very important for us to support it so that the python ecosystem as a whole can move forward. Whether the project metadata is stored in in pyproject.toml or setup.cfg seems less important as it is only consumed by setuptools (which will hopefully be kept on life support indefinitely) and doesn't burden the maintainers of other systems.

[cgahr]

I accept your reasoning and logic behind it, even if I think it is a step in the wrong direction.

You might be right with bundling setup.py. Afaict, PEP-517 support was added to setuptools in version 36.6.0. Haven't been able to find the release for pip but I would imagine that it would have been around the same time.

I think it's definitely too soon to have the project metadata in pyproject.toml though. It's not supported by the system setuptools in any version of centos or LTS ubuntu. This is very much the sort of tool which people want to install globally or in their home directory, and removing setup.cfg would prevent that in a large proportion of reasonable setups.

I think the really important bit from your pyproject.toml change is the introduction of [build-system]. This allows dependency managers to avoid guessing at what will need to be installed before having to run setup.py. It is very important for us to support it so that the python ecosystem as a whole can move forward. Whether the project metadata is stored in in pyproject.toml or setup.cfg seems less important as it is only consumed by setuptools (which will hopefully be kept on life support indefinitely) and doesn't burden the maintainers of other systems.

[bwhmather]

Wheels! The answer is wheels.

sdists should be for distributing source in buildable form. Wheels are what we should push to pypi and expect users to install. If we do this then the build system no longer matters.

I'm closing this as I think what you had @cgahr is a better basis for building wheels. Sorry for sitting on this so long while I figured things out.