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

Prevent .whl installation (OOTB) on non Win #405

Closed
wants to merge 5 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 27 additions & 3 deletions setup.py
Original file line number Diff line number Diff line change
Expand Up @@ -66,14 +66,34 @@ def run(self):
self.failure = self.failure or package_failure


try:
from wheel.bdist_wheel import bdist_wheel
class bdist_wheel_win(bdist_wheel):
def get_tag(self):
win_plats = ( # Copied the list from DistUtils
"win-amd64",
"win32",
"win-arm64",
"win-arm32",
)
tag = super().get_tag()
return tuple(tag[:-1]) + (".".join(wp.replace("-", "_") for wp in win_plats),)

except ImportError:
bdist_wheel_win = None


Comment on lines +69 to +85
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code feels really brittle. I'd like to see this project and others move away from setup.py altogether. It feels wrong or at least a hack to try to present this module as requiring Windows. It does have a runtime dependency on Windows or at least an implementation of Ctypes that supports the com types, but none of that is part of this package. Moreover, there's nothing special about the wheel that it's not installable on Unix but the sdist is. I'm not confident this unusual, mangled bdist name is going to be supported or useful. It may block releasing to PyPI (though I suspect you've tested this design).

I'm inclined to say no, let's not try to implement platform specificity here. Instead, I'd say to bring this problem to pypa/packaging-problems and explain the use case and request/contribute a solution that any package can avail to declare platform specificity.

classifiers = [
'Development Status :: 5 - Production/Stable',
'Intended Audience :: Developers',
'License :: OSI Approved :: MIT License',
'Operating System :: Microsoft :: Windows',
'Programming Language :: Python',
'Programming Language :: Python :: 2.7',
'Programming Language :: Python :: 3',
'Programming Language :: Python :: 3.7',
'Programming Language :: Python :: 3.8',
'Programming Language :: Python :: 3.9',
'Programming Language :: Python :: 3.10',
'Programming Language :: Python :: 3.11',
'Programming Language :: Python :: 3.12',
Comment on lines +91 to +96
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used to try to keep up with all of the supported Python versions, but found it to be a maintenance nightmare. Moreover, it's redundant with the python_requires directive. Just declare Python :: 3 and ignore the sub versions.

'Topic :: Software Development :: Libraries :: Python Modules',
]

Expand Down Expand Up @@ -151,6 +171,7 @@ def run(self):
cmdclass={
'test': test,
'build_py': build_py,
'bdist_wheel': bdist_wheel_win,
'install': post_install,
},

Expand All @@ -162,6 +183,9 @@ def run(self):
"comtypes.tools",
"comtypes.test",
],

platforms=["Windows"],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This field is poorly documented, non-standardized, and ineffective. Let's avoid it.

python_requires=">=3.7",
)

if __name__ == '__main__':
Expand Down