Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Docs] Replacement for distutils.command.install_data ? #4070

Open
1 task done
Avasam opened this issue Oct 1, 2023 · 2 comments
Open
1 task done

[Docs] Replacement for distutils.command.install_data ? #4070

Avasam opened this issue Oct 1, 2023 · 2 comments
Labels
documentation Needs Triage Issues that need to be evaluated for severity and status.

Comments

@Avasam
Copy link
Contributor

Avasam commented Oct 1, 2023

Summary

I'm looking into progressively migrating distutil usage in pywin32 (mhammond/pywin32#2119), where distutils.command.install_data.install_data is used.
https://setuptools.pypa.io/en/latest/deprecated/distutils-legacy.html#prefer-setuptools and https://peps.python.org/pep-0632/#migration-advice mention that distutils.command.* should be replaced by setuptools.command.*. However, setuptools.command.install_data does not exist. I searched the documentation for install_data and could not find any deprecation or migration mention.

OS / Environment

Windows 10
Python 3.9
setuptools 68.2.2

Additional Information

Document a migration path for distutils.command.install_data

Code of Conduct

  • I agree to follow the PSF Code of Conduct
@Avasam Avasam added documentation Needs Triage Issues that need to be evaluated for severity and status. labels Oct 1, 2023
@abravalheri
Copy link
Contributor

abravalheri commented Oct 2, 2023

Hi @Avasam, thank you very much again for working in the migration.

Any install_* command is complicated...

There is actual no replacement since setuptools no longer is responsible for installing the package itself after the Python package ecosystem moved to a "post-PEP517" era.

In a "post-PEP517" scenario, all setuptools does is to create a .whl file (a custom .zip) which is then installed by pip without calling 3rd-party code. Customisation of install_* commands may (a) fail, (b) not behave as intended, or (c) be merely used to copy the files to their correct places inside the .whl archive - not in the end-user's machine.

I had a look at your setup.py. It seems that the only customisation is to re-use the install.install_lib directory. In turn, this seems (to me, and I maybe be interpreting the code wrong) like an attempt to abuse data_files/install_data to actually install package data or "synthetize on the fly" new packages1.

If that is the case, wouldn't it be a better option to use package data directly instead and/or package_dir?
Maybe you will also need a custom build step (example) for placing pywin32.pth (or other non-Python files directly inside site-packages).

Footnotes

  1. If I am not mistaken, any folder in install.install_lib ends up in the site-packages folder, which is in sys.path. Any folder inside of a directory in sys.path is package itself (more specifically, a "namespace package" if it does not contain an __init__.py).

@Avasam
Copy link
Contributor Author

Avasam commented Oct 2, 2023

Thank you for all the references and direct documentation links. This will require some exploration on my part, and fully understanding what and why pywin32 does so. (so far my interpretation is the same, pywin32 does programmatically and dynamically create multiple packages).
Might be a while though because this is low priority until pywin32 officially stops providing .exe installers, and running the setup script directly (which they already deprecated in favor of pip install)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Needs Triage Issues that need to be evaluated for severity and status.
Projects
None yet
Development

No branches or pull requests

2 participants