-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Disable installation of Windows-specific files on non-Windows systems #1
Comments
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): Those files are windows launchers for the launching scripts on Windows systems. The executables must be present in the package in order for Windows users to be able to reliably launch scripts. Eventually, these launchers should be replaced by PEP 397 launchers, but for now, they're a necessary part of the source distribution. |
Original comment by arfrever (Bitbucket: arfrever, GitHub: arfrever): I agree with presence of *.exe files in tarballs, but I think that setup.py could skip installation of *.exe files on non-Windows systems. (MANIFEST.in already includes these files.) |
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): I have some concerns about the patch as applied. The patch adds additional dependency on MANIFEST.in (as you indicated). However, this new reliance renders fragile another objective (distribute #372). We would like to eliminate the (redundant) reliance on MANIFEST.in and rely instead only on packaging metadata as supplied setup.py. With this patch and with MANIFEST.in removed, however, if one builds the sdist on anything but Windows, it will be missing the files in the sdist. In my mind, having a cleaner declaration of package parameters (in one file, setup.py) is of greater value than of not having Windows executables installed on Unix operating systems, as the former can cause packaging errors, while the latter is only an annoyance. Thoughts? |
Original comment by rassie (Bitbucket: rassie, GitHub: rassie): This seems to be broken again, at least with
|
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): It works for me. Using a source checkout of both Setuptools 2.2 and the latest tip on Ubuntu 14.04:
That is, no executables are found. Is it possible that SETUPTOOLS_INSTALL_WINDOWS_SPECIFIC_FILES is set on your host (or by pip)? Since I can't replicate the behavior on a Linux box, I must conclude the problem is resolved, but do please feel free to delve into the problem further and provide more detail about what might be going wrong. |
Suggestions for improvements over PR 3307
Refactor `StaticModule.__getattr__` and fix `ast.AnnAssign` edge case
Remove extraneous question mark.
Originally reported by: atodorov (Bitbucket: atodorov, GitHub: atodorov)
Hi guys,
I'm not sure if this is a bug but it seems awkward to have Windows executables in a source release which I install on Linux:
setuptools/cli-arm-32.exe : PE32 executable (console) Unknown processor type 0x1c4, for MS Windows
setuptools/gui-arm-32.exe : PE32 executable (console) Unknown processor type 0x1c4, for MS Windows
setuptools/cli-64.exe : PE32+ executable (console) x86-64, for MS Windows
setuptools/cli-32.exe : PE32 executable (console) Intel 80386, for MS Windows
setuptools/gui-32.exe : PE32 executable (GUI) Intel 80386, for MS Windows
setuptools/gui-64.exe : PE32+ executable (GUI) x86-64, for MS Windows
For more info see (ADD-ON INFO button):
http://www.dif.io/updates/distribute-0.6.10/distribute-0.6.43/17481/
The text was updated successfully, but these errors were encountered: