ssssam commented on PR #1714: URL: https://github.com/apache/buildstream/pull/1714#issuecomment-1214783550
Useful comments, will update this soon and include doc updates. > This adds a lot of complexity to setup.py, I wonder if we need to worry about upstream python deprecating setup.py and if so, whether their alternatives will provide the flexibility we now require. When the Python community talk about deprecating setup.py, they do not mean "everyone has to remove their setup.py file." They are talking about having a standard build API for Python. In the old days, the official way to build a Python project was, "run a file named ./setup.py", and if that file didn't exist then it was considered a bad project doing non-standard things. Except there was no written standard anywhere, and some people wanted to use tools that weren't setuptools like Flit or Hatch. There is now a [written standard](https://peps.python.org/pep-0517/), the official way to build a Python project is via this well-defined API configured in the `pyproject.toml` file. The configuration can continue to say "build this project by running setuptools", and setuptools is not deprecated. What is deprecated is the assumption that every project uses setuptools, and the assumption that running `setup.py` directly should work in every Python package. Meanwhile setuptools are adding support for declarative configuration via [pyproject.toml](https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html) or [setup.cfg](https://setuptools.pypa.io/en/latest/userguide/declarative_config.html), which is nice and we should use this where possible. AFAICS not everything can be done declaratively, e.g. Cython still requires writing code in setup.py. I've not seen any hint that setuptools are planning to deprecate use of setup.py. That said, there is quite some code added to setup.py :) Adding support for custom version styles to versioneer would help us reduce that, but i didn't have time to dig into it. > This will run CI on the wheels we upload only at tag/release time, which presents some workflow complexity > Currently we test everything that is required when merging a commit to master, so we already know that CI will pass on a tag > I don't think we want to build wheels and run CI on wheels for every merge to master, CI is already quite lengthy The PR currently runs wheel build + test on each merge to master. I thought the same thing that the release manager will not want to discover horrifically broken wheels only at the point on Friday night when they push a new tag. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
