On 17 July 2014 17:04, David Genest <david.genest@ubisoft.com> 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. 2. What you're doing is not supported behaviour (although I appreciate the fact that it's useful to you). 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. You can probably include a project-specific hack if you're so inclined, but this shouldn't be added as a feature of setuptools. Longer term, maybe your use case is something that we could support via Metadata 2.0. I'm honestly not sure at the moment, as your description isn't very specific. What "external binary files" do you package? If they are DLLs (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)? 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*. Paul