> On 17 July 2014 17:04, David Genest <[email protected]> wrote: > > I would like to know what is the take in the community on this. > > My view would be: > > 1. The scripts argument is for *scripts* not binary files, so it is perfectly > correct to open them in text mode, do line ending translation, etc.
I see that. But on windows, beside naming, the scripts argument is used to populate the Scripts directory (which are not only scripts, but sometimes setuptools wrappers - clearly executable). Cross-platform can be achieved by bundling unix and windows variants at setup.py time. > 2. What you're doing is not supported behaviour (although I appreciate the > fact that it's useful to you). It is de-facto. We have been using this "functionality" to package our windows only binary executables in an egg (using install). Wheels are supported also (but I agree, pip or wheel cannot infer the platform). > 3. The scripts feature is generally discouraged in favour of entry points. > 4. By including binaries, you make your package non-portable, and do so in a > way that setuptools/wheel/pip cannot spot, so (for example) if you were to > build a wheel it would not be recognised as architecture-specific. I agree that they would not be portable, but in a Windows only situation, this does not pose a problem. I'm not using the feature to publish a cross-platform solution, it is used to publish a package in-house. But the current setuptools tooling is perfectly adapted to this. Also, the binary delivery mechanism is a needed feature, especially on windows. The current API permits it's use now (on unix, or more precisely, platforms where the 'b' mode has no effect when opening files). No checks are being performed. Why should it be different on Windows ? > very specific. What "external binary files" do you package? If they are DLLs In our situation, it is an executable embedding python, but it could be any binary auxiliary executable useful for the package. Dlls are only another binary example of what is needed by the package (and loadable by windows because on the path). > (as you mention) how would they work on Unix? I'm a bit confused here, as > you mention the script handling being OK for you on Unix, and yet you're > talking about DLLs, which are for Windows... If this is intended to be a > single- > platform solution, how do you anticipate communicating that fact to the build > and install tools (wheel, pip, etc)? I was probably too vague. I meant that the existing functionality supports binary files on unix, albeit not in a cross-platform way. In other words, if you specify a binary file in scripts, it will be copied over without being broken. It is not the case on Windows. I am not up to date with metadata, but I agree that it should be communicated in the tools. > > Thanks for raising the issue, it sounds like you have a use case that isn't > well > supported at the moment. But I agree with Jason that this shouldn't be > forced into the scripts functionality, which is, after all, intended for > *scripts*. Acknowledging that the current script solution is not for cross-platform transportation of binaries, the problem is that it is difficult to package arbitrary binary executables that are available in a virtualenv. Helper executables, or any other auxiliary executables. Right now, AFAIK, on python2, (and python3) it is not possible to publish a binary executable by other means than the script parameter. Knowing that the install works right now, I would think that the develop command should at least behave the same. David. _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
