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
bb-migration opened this Issue May 25, 2013 · 9 comments

Comments

Projects
None yet
1 participant
@bb-migration

bb-migration 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/


@bb-migration

This comment has been minimized.

bb-migration 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.

@bb-migration

This comment has been minimized.

bb-migration commented Jun 9, 2013

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


Removing version: 0.6.43 (automated comment)

@bb-migration

This comment has been minimized.

bb-migration 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.

@bb-migration

This comment has been minimized.

bb-migration 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.

@bb-migration

This comment has been minimized.

bb-migration commented Jun 12, 2013

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


Fixed in revision 1148e20b79e7a549080afdaedfb92cc5db5e8057.

@bb-migration

This comment has been minimized.

bb-migration 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?

@bb-migration

This comment has been minimized.

bb-migration commented Jun 20, 2013

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


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

@bb-migration

This comment has been minimized.

bb-migration 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

@bb-migration

This comment has been minimized.

bb-migration 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.

jaraco pushed a commit that referenced this issue May 2, 2016

jaraco pushed a commit that referenced this issue Jan 5, 2018

xoviat
Merge pull request #1 from pypa/master
Merge recent changes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment