1. PyPA
  2. Python Packaging Authority Projects
  3. setuptools
Issue #1 resolved

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

Alexander Todorov
created an issue

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/

Comments (11)

  1. Jason R. Coombs

    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.

  2. Jason R. Coombs

    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.


  3. Nikolai Prokoschenko

    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
  4. Jason R. Coombs

    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.

  5. Log in to comment