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

Disable installation of Windows-specific files on non-Windows systems #1

Closed
ghost opened this issue May 25, 2013 · 9 comments
Closed

Comments

@ghost
Copy link

ghost commented May 25, 2013

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/


@ghost
Copy link
Author

ghost commented May 25, 2013

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.

@ghost
Copy link
Author

ghost commented Jun 9, 2013

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


Removing version: 0.6.43 (automated comment)

@ghost
Copy link
Author

ghost commented Jun 9, 2013

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.)
I can implement this change if there are no objections.

@ghost
Copy link
Author

ghost commented Jun 10, 2013

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):


I'm not convinced of the value in removing these. I guess it just annoys Unix users, so it would probably be okay to omit them.

@ghost
Copy link
Author

ghost commented Jun 12, 2013

Original comment by arfrever (Bitbucket: arfrever, GitHub: arfrever):


Fixed in revision 1148e20b79e7a549080afdaedfb92cc5db5e8057.

@ghost
Copy link
Author

ghost commented Jun 18, 2013

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?

@ghost
Copy link
Author

ghost commented Jun 20, 2013

Original comment by arfrever (Bitbucket: arfrever, GitHub: arfrever):


Revision 3757c10aaec8fac1c0e84d8be6697dc6be377e10 should allow to eliminate usage of MANIFEST.in.

@ghost
Copy link
Author

ghost commented May 23, 2014

Original comment by rassie (Bitbucket: rassie, GitHub: rassie):


This seems to be broken again, at least with setuptools 2.2 on SLE11 SP3:

$ mkvirtualenv exetest
New python executable in exetest/bin/python
Installing setuptools, pip...done.

$ cdsitepackages

$ find -iname '*.exe' | grep setuptools
./setuptools/gui-32.exe
./setuptools/cli-64.exe
./setuptools/cli-32.exe
./setuptools/gui-64.exe
./setuptools/cli-arm-32.exe
./setuptools/cli.exe
./setuptools/gui-arm-32.exe
./setuptools/gui.exe

@ghost
Copy link
Author

ghost commented May 23, 2014

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:

vagrant@vagrant:/vagrant/projects/setuptools$ python3.4 setup.py install --quiet --root target && find target -iname '*.exe'
running install
running build
running build_py
running install_lib
running install_egg_info
running egg_info
writing requirements to setuptools.egg-info/requires.txt
writing dependency_links to setuptools.egg-info/dependency_links.txt
writing setuptools.egg-info/PKG-INFO
writing entry points to setuptools.egg-info/entry_points.txt
writing top-level names to setuptools.egg-info/top_level.txt
reading manifest file 'setuptools.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'setuptools.egg-info/SOURCES.txt'
removing 'target/usr/local/lib/python3.4/dist-packages/setuptools-2.2dev-py3.4.egg-info' (and everything under it)
Copying setuptools.egg-info to target/usr/local/lib/python3.4/dist-packages/setuptools-2.2dev-py3.4.egg-info
running install_scripts
Installing easy_install-3.4 script to target/usr/local/bin
Installing easy_install script to target/usr/local/bin

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.

@ghost ghost added major bug labels Mar 29, 2016
@ghost ghost closed this as completed Mar 29, 2016
jaraco pushed a commit that referenced this issue May 2, 2016
jaraco pushed a commit that referenced this issue Jan 5, 2018
jaraco added a commit that referenced this issue Jul 2, 2020
abravalheri pushed a commit that referenced this issue Apr 4, 2022
abravalheri pushed a commit that referenced this issue May 16, 2022
Suggestions for improvements over PR 3307
abravalheri pushed a commit that referenced this issue Jun 19, 2022
Refactor `StaticModule.__getattr__` and fix `ast.AnnAssign` edge case
abravalheri pushed a commit that referenced this issue Aug 12, 2022
Remove extraneous question mark.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

0 participants