Closed Flamefire closed 2 years ago
Since this is a packaging build-time problem, I think we can just ask users who don't want to use pre-packaged installation sources to have an updated environment. Please reopen if this is not a good call.
It is not a good call. As I wrote in https://github.com/templateflow/python-client/issues/67 the official documentation states that this change is required. And as also written at https://github.com/templateflow/python-client/issues/67#issuecomment-919814909 it isn't even clear what exactly (seemingly) has to be updated to fix the issue.
I don't understand why this discussion at all: Does this change hurt in any way? It is correct as per the documentation and fixes a real bug in some environments and doesn't introduce any new issues.
@Flamefire, first let me say that I understand your frustration of having attempted to investigate the issue and having put together a patch to then see I closed it. I truly recognize these efforts and thank you for them. I'd also like to thank you in advance for your understanding if I didn't explain the call sufficiently.
We follow PEP518 for specifying the build dependencies, and therefore this is found in the pyproject.toml
file:
You'll see what are the minimal version requirements for building the package, done following PEP517. This brings me to the second step of the rationale behind closing the PR: for this package we encourage using pre-built packages as we post them on Pypi. We assume that a user who is advanced enough to (for whatever reason) build the package themself from sources, should be able to follow our (admittedly not written down) packaging principles.
Accepting this PR means risking that our packaging stops building at some point in the future when, for instance, setuptools or setuptools_scm make changes to the setup arguments. Because the maintainers don't have the bandwidth to worry about packaging, as long as our unit tests on packaging are working (https://github.com/templateflow/python-client/blob/master/.github/workflows/pythonpackage.yml) we are happy.
I hope these explanations will alleviate the discomfort I caused by my insufficient justification above and again I appreciate your understanding.
If there is any reason why this project should support old versions of setuptools_scm (in this case), please let us know and we will reconsider your patch right away. But at the moment I don't see any incentives in trying to support earlier versions.
Fixes #67
Alternatively the setup.py could be removed but this requires further testing if setup.cfg is still handled correctly or have to be moved into pyproject.toml