Skip to content

Conversation

@nils-werner
Copy link
Contributor

Your current approach of moving stuff around in setup.py is very unclean:

Even without passing an actual action (install, sdist etc.) the script will copy stuff around. Also, you will not be able to build source packages for Windows when you are on any other operating system.

My solution: Always ship the DLLs and make the distinction in your actual module, not in setup.py.

@mgeier
Copy link
Contributor

mgeier commented Nov 18, 2014

Should the dlls be part of the sdist tarball?
I tried it (on Linux) and they weren't.
They were included with bdist*, however.

@nils-werner
Copy link
Contributor Author

Yes, they should be. Otherwise you will not be able to build it from PyPI. I have done something similar recently and will check what I did to fix it.

@nils-werner
Copy link
Contributor Author

Regarding sndfile32bit.dll: I don't think it makes the code more readable so I would advise against it.

@nils-werner
Copy link
Contributor Author

OK, I have implemented a solution that packages the DLLs in the sdist ZIP file. However I cannot test if Windows will be able to find the files in their new location. Can anybody check?

@bastibe
Copy link
Owner

bastibe commented Nov 18, 2014

Thank you for your contributions. Any simplification of the binary DLL handling is greatly appreciated. At the time, I merely went with the thing that worked, which is probably not the most elegant solution.

However, I wouldn't want to copy all binaries into all bdist packages.

Also, I don't think that we need to convert PySoundFile into a package. I like the fact that you can just import pysoundfile with just the file in your working directory.

@nils-werner
Copy link
Contributor Author

Also, I don't think that we need to convert PySoundFile into a package. I like the fact that you can just import pysoundfile with just the file in your working directory.

I would go with whatever makes PIP installs more easy. I couldn't find a way to having a module and having package_data.

@bastibe
Copy link
Owner

bastibe commented Nov 18, 2014

Oh, I see.

@mgeier mgeier mentioned this pull request Nov 20, 2014
@bastibe bastibe self-assigned this Nov 24, 2014
@bastibe
Copy link
Owner

bastibe commented Nov 24, 2014

We'll try to get rid of the binaries altogether. We'll reevaluate this question once that process is done.

@mgeier
Copy link
Contributor

mgeier commented Jan 10, 2015

I created an alternative to this PR: #98.

@mgeier
Copy link
Contributor

mgeier commented Jan 15, 2015

I'm closing this, see #98 for the reasoning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants