Problem running 'setup.py install'

[njh]

I am having trouble running setup.py install on Mac OS and Linux:

$ python setup.py install --prefix=/tmp/pycam --single-version-externally-managed --record=installed.txt
running install
running build
running build_py
running build_scripts
running install_lib
running install_data
running install_egg_info
running egg_info
writing pycam.egg-info/PKG-INFO
writing top-level names to pycam.egg-info/top_level.txt
writing dependency_links to pycam.egg-info/dependency_links.txt
reading manifest file 'pycam.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no files found matching 'pycam'
warning: no files found matching '*' under directory 'desktop'
warning: no files found matching '*.py' under directory 'src'
writing manifest file 'pycam.egg-info/SOURCES.txt'
removing '/tmp/pycam/lib/python2.7/site-packages/pycam-0.6_svn-py2.7.egg-info' (and everything under it)
Copying pycam.egg-info to /tmp/pycam/lib/python2.7/site-packages/pycam-0.6_svn-py2.7.egg-info
running install_scripts
changing mode of /tmp/pycam/bin/pycam to 755
error: install_script 'pycam_win32_postinstall.py' not found in scripts

Work around is to delete setup.cfg but not sure what the proper fix is.

[SebKuzminsky]

I ran into the same problem. I worked around it by commenting out all the lines in setup.cfg that begin with "install_script".

I think those lines intend to specify a special helper script needed on windows, which is not needed on linux. For some reason that i don't understand, those scripts are getting used on Linux too, which breaks things there. Maybe the syntax of setup.cfg changed, or maybe that change was never tested on Linux?

[sumpfralle]

I am using only linux systems - thus it is more likely a change that sneaked in after v0.5.1. (I reorganized a lot of stuff after that release)

I always feel clumsy whenever I touch a setup.py script - and this one is more than four years old. Whoever feels more inspired: you are invited to improve or rewrite it freely.

[SebKuzminsky]

I've pushed a workaround for this problem to master, it's included in the 0.6 release. I'm going to close this issue now and let a hypothetical future Windows platform maintainer worry about reviving the windows port.

[njh]

cc5686ce2774f5b54dca4bcea78d0770a0cc4b02

Yeah, probably a good idea. I was scared to touch the Windows stuff because I have no way of testing it. Just disabling good enough for now.