Installation instructions

[bastibe]

I have been using Python(x,y) and WinPython distributions, and I haven't yet installed any new packages. I was reading the installation instructions from PySoundFile, and I was confused on a few items.

The PySoundFile instructions say that you need the library libsndfile installed on your computer. When using the Windows installers, isn't libsndfile included and its DLL put in the PySoundFile folder?

The PySoundFile instructions say that you also need CFFI. Python(x,y), which is for Windows, already contains CFFI. The Anaconda distribution contains CFFI for Linux and OSX. The PySoundFile instructions suggest using WinPython, but wouldn't one of these other distributions be simpler since they already contain CFFI?

The Anaconda distribution now has installers for Python 2.7 and 3.4, with Python 3.3 available only as an add-on environment (with no OS integration). I intend to move to Python 3.4. I request that the next release of PySoundFile support Python 2.7, 3.3 and 3.4.

[bastibe]

I prefer WinPython over Python(x,y) for reasons very unrelated to PySoundFile. I just love the fact that a WinPython installation is simply a directory, and you can copy that directory around without breaking anything. There are many other reasons, such as the availability of optimizations, support, or integrated development environments, which might sway one's choice one way or another. At the moment, I would recommend WinPython in Windows, and Anaconda on OS X.

Libsndfile is indeed included in the Windows installers. It does not contain CFFI or PyCParser though. Whether or not those are available in your distribution of choice is something you have to find out yourself. If you have a C compiler installed, pip install cffi might even work. I have not seen that one working on Windows yet though.

I would love to provide binary libraries on OS X as well, but I don't know how. Maybe pip wheels or conda binstar will provide something like that in the future. For the time being, users will have to install the libraries manually though. At least, homebrew makes that relatively painless.

I think that the binary installers for Windows/Python3.3 are compatible with Python 3.4 as well. I'm not 100% sure though. I will recut the installers once our refactor is complete though, and I'll use the most recent version of WinPython at that time. I'll have to look into Anaconda to see whether that would be a feasable route as well. The availability of the conda package manager certainly makes it very interesting.

[Whistler7]

Anaconda also includes PyCParser!

I can understand how the portable installation of WinPython makes it ideal for developing packages for many versions of Python on one machine. I haven't yet used Anaconda, but it seems to have the same feature.

The Python(x,y) team is working on a version for Python 3.4:
https://groups.google.com/forum/#!topic/pythonxy/VxeyfJ1SY6E
Would be great if PySoundFile is ready for Python 3.4, even if WinPython isn't (yet).

Any estimate of when the next release of PySoundFile will be?

[bastibe]

Any estimate of when the next release of PySoundFile will be?

Hard to say. We are working hard on implementing a test bench right now. Then, there's tell, blocks, read_bytes, write_bytes, and quite a bit of administrative stuff. I'd say it's still a month or two until we release. Feel free to use the latest repository version though. It is quite usable already, and features are pretty stable once they are merged.

[mgeier]

This issue overlaps with #26.

I think it's a very good idea to extend the installation instructions.
It might be good to create separate sections for Win, OSX and Linux (and other Unices?).
I think it's a good idea to have one recommended distribution on Windows, but it's also good to mention a few alternatives.

[Whistler7]

As I was looking at Python(x,y), I noticed that it also contains PyCParser. Thus, for a scientific Python user using only Python 2.7 on Windows, Python(x,y) seems like the simplest way to get PySoundFile because it already contains CFFI and PyCParser.

I am moving to 64-bit Python 3. I have WinPython installed. My concern, however, is that WinPython is "abandonware" since the developer no longer uses Python in his job. If I need updates and WinPython remains dead, I may move to Anaconda while waiting for Python(x,y) to support 64-bit Python 3.

This article may be helpful for building Python extensions with a different version of Visual Studio than what was used to build a particular Python release:
http://p-nand-q.com/python/building-python-33-with-vs2013.html
I hope it is helpful for building for Python 3.4.

[Whistler7]

I see the Anaconda repository now contains CFFI for Windows (in addition to PyCParser). For Python 3.3 and 3.4, Anaconda supports CFFI for Windows & Linux (both 64-bit and 32-bit). For Python 2.7, Anaconda supports Windows, Linux & MacOSX (64-bit only for MacOSX, both 64-bit and 32-bit for the others). I suggest that PySoundFile installation instructions for Anaconda include "conda install cffi".

I see that the WinPython community forum has a thread where members are in the process of building WinPython for Python 3.4. Maybe WinPython is not dead. :)

[bastibe]

Personally, I have switched to Anaconda a while ago. That conda package manager is just amazingly useful. I even use conda in my non-Anaconda Python installations.

If Anaconda now supports CFFI, I think we should change the installation instructions to use Anaconda. This would shorten the Windows installation instructions to conda install numpy cffi, "run the installer". I am hoping that we can further improve this to conda install pysoundfile in the future.

[bastibe]

I just realized that pip install pysoundfile fails on Windows, if it is not run from the binary installer, since it won't find the DLLs.

[bastibe]

See #26 for implementation

[mgeier]

I just tried manually installing libsndfile on Windows 7.
It's not as straightforward as I would have hoped, but in the end I was able to load the DLL with ffi.dlopen().

I downloaded the "installer" from http://www.mega-nerd.com/libsndfile/#Download (this is the actual link: http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.25-w64-setup.exe).

It seems that it doesn't "install" anything, it merely extracts a bunch of files to a given directory. By default, this was "...\Downloads\libsndfile", I don't know if this is always the case.

The .dll-file can be found in the bin-subdirectory, it is named libsndfile-1.dll.

There are (at least) two ways to make Python find this DLL:

• move the file to C:\Windows\System32
• add the bin-directory to the PATH variable

I had to change the dlopen() call to _ffi.dlopen('libsndfile-1') and then it worked!

We should probably try a list of possible library names, something like ['sndfile', 'libsndfile', 'libsndfile-1'].

I would be quite complicated to explain this to our users, but at least we could get rid of the DLL file in our repository. And we wouldn't have to create Windows installers for all Python versions.

If this sounds too complicated, wouldn't it be a good idea to create a separate project which provides a proper Windows installer for libsndfile (that actually installs the library on the system)?
I, however, have no idea how to create a Windows installer and if there is open-source infrastructure available to do this.
We could also ask Erik if he wants to extend the official installer or someone could offer to help him.
I didn't find the code to create the installer in his github repo, but I also don't know what I'm looking for.

Side note: I found this https://github.com/lordmulder/libsndfile-MSVC, which might be interesting for Windows users which want to use named pipes.

[bastibe]

I tried that too, and decided that it is too complicated. I think we should stick with the binary installers for the time being.

[mgeier]

I asked Erik if he wants to change the installer: libsndfile/libsndfile#89.

For the case that he doesn't, I already had a quick look for how to create Windows installers and found three possibilities: Inno Setup, NSIS, WiX Toolset.

Any more suggestions?

I guess it shouldn't be hard to create an installer that shows the LGPL and then installs a DLL to the Windows system directory.
It might even be possible to create a combined 32bit/64bit installer.

[bastibe]

Do you mean an installer for PySoundFile, or an installer for libsndfile?

What is the correct procedure to install libsndfile on a Windows-system anyway?

• Install it anywhere, and then modify the system/user PATH. This is what Git and Qt do.
• Install it into System32 (64 bit) / SysWow64 (32 bit). That sounds evil.
• Install it in the Python load path. How would one deal with non-globally installed Pythons?

[mgeier]

I mean an installer for libsndfile, which would make all PySoundFile installers obsolete (because pip install can be used then).
The installer should have no relation to PySoundFile and not even to Python itself.

What is the correct procedure to install libsndfile on a Windows-system anyway?

To be honest, I have no clue. I'm neither a Windows user nor a Windows developer. And I'm thankful for that.

I was going to try the second option, even if it's evil. I think as long as the software for creating an installer provides a means for putting files there, I might as well use it.

But now that you mention it, the first option is probably much better.
I was initially only interested in installing the DLL, but the installer might as well install the libsnfile tools. Those would need their separate directory anyway which would have to be in the PATH. If the DLL gets copied into the same directory, it'll automatically be found as well.

I think the third option is the worst because it will be the hardest to get right.
There may be different versions of Python installed, and even different interpreters like CPython and PyPy. I'm sure there is a mess of environment variables the installer would have to know about.
Also, it would only reliably work if Python is installed before libsndfile (setting all the environment variables). If libsndfile is installed before any one of the many Python versions you might want to install, it may not know where to install itself.

[bastibe]

Just as a side note: This would be tremendously useful for portaudio, too!

[bastibe]

For the moment, we should probably keep on relying on the bdist installer, since there doesn't appear to be a better solution for Windows. This is what is currently documented in the README since we merged #26.

Should we postpone further improvements after 0.6.0?

[mgeier]

It depends on how quickly Erik reacts. He already asked about some details in libsndfile/libsndfile#89 (comment), so I guess/hope he is considering changing his installer.

Probably he's already working on it ...?

OTOH, I think it doesn't really matter if we do this now or after 0.6.0, so I'd say if Erik doesn't provide a new installer until we have closed all other issues/PRs for 0.6.0, we should just postpone this.

[mgeier]

Erik confirmed that he will include the discussed changes to the installer in the next release (whose date is yet unknown): libsndfile/libsndfile#89

[bastibe]

That's great news! Thank you for the effort!

[Whistler7]

For Anaconda users, how about publishing a conda package to install PySoundFile and the libsndfile DLL in a folder that is only seen by PySoundFile? This would allow users to have both 32-bit and 64-bit Anaconda versions installed simultaneously, which I have done successfully in the past (without PySoundFile or libsndfile).

WinPython now contains cffi and pycparser, and it is 100% built using wheels. WinPython is on the leading edge of support for Julia and IPython/Jupyter. What about offering PySoundFile as a wheel package for WinPython and other non-Anaconda distributions? This link might be helpful: http://pythonwheels.com/

[bastibe]

Both conda binstar packages and pip wheels still require the user to supply extra command line arguments compared to "regular" conda/pip packages, right? Do you think that they sufficiently widely known to warrant the effort?

Are they needed for Windows only? Mac would be nice, I guess. I fear that cross-distro support on Linux might be difficult?

[bastibe]

Thank you for the suggestions. The latest commit should be mergeable, then?

[mgeier]

Yes, perfect!