Running setup.py as a script and its use as a CLI tool are deprecated

[Avasam]

https://packaging.python.org/en/latest/discussions/setup-py-deprecated/#is-setup-py-deprecated

python setup.py and 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 Unable to install directly from Git via pip #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.

    pywin32/pyrightconfig.json

    Lines 45 to 51 in 9ef5061

    	// Too many dynamically generated modules. This will require type stubs to properly fix.
    	"reportMissingImports": "warning",
    	// IDEM, but happens when pywin32 is not in site-packages but module is found from typeshed.
    	// TODO: Is intended to be fixed with an editable install
    	// Since we're a library, and not user code, we care less about forgetting to install a dependency,
    	// as long as we have its stubs. So just disabling for now is fine.
    	"reportMissingModuleSource": "none",

[Avasam]

@zooba Given you added the ARM64 cross-compilation CI job. Any idea how to migrate this command to not call setup.py ?

pywin32/.github/workflows/main.yml

Lines 91 to 96 in c6acaf5

	- name: Obtain ARM64 library files
	run: |
	python .github\workflows\download-arm64-libs.py .\arm64libs
	- name: Build wheels
	run: python setup.py build_ext -L .\arm64libs --plat-name win-arm64 build --plat-name win-arm64 bdist_wheel --plat-name win-arm64

[zooba]

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

[Avasam]

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 github/roadmap#970 (comment)

[zooba]

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).