Running `setup.py` as a script and its use as a CLI tool are deprecated
https://packaging.python.org/en/latest/discussions/setup-py-deprecated/#is-setup-py-deprecated
python setup.pyand the use of setup.py as a command line tool are deprecated
https://setuptools.pypa.io/en/latest/deprecated/commands.html#running-setuptools-commands
running python setup.py directly as a script is considered deprecated.
pywin32 itself should move away from it, I have yet to investigate everything needed for pywin32 to move away from it.
Relates to #2119
To stop using python setup.py, the --skip-verstamp flag needs to be changed. Either trying to pass it through:
- --config-settings and --build-option / --global-option
- Environment variables
- Change version stamping to not have a bootstrapping issue in the first place, rendering this flag obsolete.
- or another mechanism I'm not aware of
Being able to build / install from pip install will open the door to:
- Building / installing the latest in-development version directly from a GitHub branch https://github.com/mhammond/pywin32/issues/2306
- editable installs, which itself:
- Allows developer to test/import modules directly from the repo https://setuptools.pypa.io/en/latest/userguide/development_mode.html
- Helps static checkers be more aware of which files should be present, during development. https://github.com/mhammond/pywin32/blob/9ef506138adc28b848cc537a9dc64cd18d2fcabd/pyrightconfig.json#L45-L51
@zooba Given you added the ARM64 cross-compilation CI job. Any idea how to migrate this command to not call setup.py ?
https://github.com/mhammond/pywin32/blob/c6acaf54b441da947f98f8c9494a740ecdbc814a/.github/workflows/main.yml#L91-L96
setuptools supports inserting an additional configuration file through environment variables, you can see how cibuildwheel sets up cross-compiling here: https://github.com/pypa/cibuildwheel/blob/main/cibuildwheel/windows.py#L141
Thanks! I think yesterday I finally figured out how to use --config-settings + --build-option to have a command equivalent to before in #2396 (there's a surprising lack of information about how to use these flags correctly).
GitHub's ARM-based Windows runners should be freely publicly available by the end of the year anyway, so whatever works for now.
https://github.blog/changelog/2024-06-03-actions-arm-based-linux-and-windows-runners-are-now-in-public-beta/
We expect to begin offering Arm runners for open source and personal accounts by the end of the year.
https://github.com/orgs/community/discussions/19197#discussioncomment-10895290
The upcoming release will add arm64 as another option for our standard hosted runners - which means they will be free in public repositories and there will be a label to target them.
Update: Looks like the roadmap for this has been moved to Q1 2025 – Jan-Mar https://github.com/github/roadmap/issues/970#event-15372763670
Update 2: Linux arm64 runners are now freely publicly available, Windows runners are being worked on, no ETA: https://github.com/orgs/community/discussions/148648#discussioncomment-11920058
Yeah, cross-compiling is nice if you want to do all the builds in a single job and then run tests on the target machines, but it's optional. Really the only difference is that setuptools assumes you're targeting the current platform (and only recently gained the ability to detect Windows ARM64 properly).