Passing binary files as 'scripts' causes errors at develop and install. #210
Comments
1 similar comment
|
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): David, I'm not sure distutils/setuptools should necessarily support arbitrary binaries as 'scripts'. In the Python documentation, it defines scripts as "Scripts are files containing Python source code". Under this assumption, it's reasonable for setuptools to open these files as text. I acknowledge that you've created pull request 60 to address the regression, but I'm reluctant to accept that pull request as it adds quite a bit more undocumented special casing, creating more untested, implicit requirements on setuptools. |
|
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): What I'm failing to understand is why easy_install.install_egg_scripts doesn't encounter this same error, since it apparently uses dist.get_metadata to load the script as a binary blob. Can you provide a reference to a project (preferably one with minimal dependencies and system requirements) that experiences this failure? |
|
Original comment by davidoff (Bitbucket: davidoff, GitHub: davidoff): As I understood the feature, and the usage we have in a normal install, is that scripts are copied to the python Scripts installation directory. On windows, this brings a fine way to include things in a package that can be bundled and used with the package, binary or not. For example, we bundle a custom version of the python interpreter built with another build system (but it could be any other auxiliary binary support file). Let's call it myPython.exe (with it's runtime dependencies (dll etc)). The package to be installed is ourPythonDriver.py. Now when people install ourPythonDriver.py, they get also get myPython.exe installed, and it is available in the environment. It is very practical that this feature works also with the develop command, and having a different semantics from the install and the develop command seems like a bug. Even if binary support is not explicitly mentioned in the docs, using binary files specified as scripts break only on windows because of the line ending translation caused by text mode opening. This happens only with the develop command. |
|
Original comment by davidoff (Bitbucket: davidoff, GitHub: davidoff): You can easily clone a sample project I created on GitHub to see the problem https://github.com/davidovich/develop_breakage_on_windows With pull request #60, this does not crash. Without it, it crashes. |
ghost
added
|
Even not on Windows, the package presented fails to build on Python 3 on Unix: Notice that it fails to It still feels wrong to me to be hacking scripts to support something which they weren't intended to support, so here are a few options to consider:
|
jaraco
changed the title
|
Accordingly, as a bug, I'm declaring this invalid, though I welcome follow-on tickets to implement one of the suggestions above or perhaps another enhancement to better support this need. |
|
I hit this problem too - and implemented the 3rd suggestion by @jaraco (custom post-install script to copy binary over to the scripts directory). The code is here in case anyone is interested: https://github.com/benfred/py-spy/blob/290584dde76834599d66d74b64165dfe9a357ef5/setup.py#L42 I'm using this to distribute a rust binary with pypi (so you can go |
|
I just ran into this while porting to Python 3 a data_files = [ ('bin', [<my binary>]) ]One important difference vs using |
Apparently you can no longer install arbitrary binaries using `scripts`. Instead you need to use `data_files` now. Discussion of error in Python 3 when trying to use `scripts` to install binaries here: pypa/setuptools#210. Basically, you get an error about a failed parse when setup tools tries to rad the binary as a Python or #! script :P
Apparently you can no longer install arbitrary binaries using `scripts`. Instead you need to use `data_files` now. Discussion of error in Python 3 when trying to use `scripts` to install binaries here: pypa/setuptools#210. Basically, you get an error about a failed parse when setup tools tries to rad the binary as a Python or #! script :P
Actually I just tried and it looks that now the permissions are been correctly kept. |
|
@ntc2 Hi, when I use |
|
@DongqingSun96 sorry, I don't remember anything about how this works, and it sounds like it might have changed since my comment above. |
|
@DongqingSun96 Please open a new issue, describing your issue - what commands you ran, what versions of Python and Setuptools you were using, what you encountered, and what you expected instead. In particular, if you can describe the problem in a way that the team can replicate, that would go a long way to getting more insight into the issue. |
Script files to be copied in the develop command should be open in binary mode. Fixes pypa#210.
Originally reported by: davidoff (Bitbucket: davidoff, GitHub: davidoff)
If you specify a binary file to the scripts= parameter of setup, the setup.py develop command copies the script with bytes 0D converted to 0A, garbling the binary data.
I have traced this to the text mode file opening in setuptools/command/develop.py:165 (introduced in c9e11fdff773).
If I change from open(script_path, 'rU') to open(script_path, 'rb') the binary files are copied correctly.
The text was updated successfully, but these errors were encountered: