Sloooowly remove SoundFile.__len__()

[mgeier]

See #199.

This will be a breaking change and should therefore be very gentle, with long breaks between those action points:

• Deprecate .__len__() and introduce .frames as replacement (Add SoundFile.frames attribute and deprecate __len__() #206); released in v0.10.1 (2018-03-02)
• Generate a deprecation warning when len() is used
• Remove .__len__() and remove .__bool__()/.__nonzero__() which becomes obsolete

[bastibe]

I agree! This seems to be the right course of action. Thank you for taking charge!

[mgeier]

Great! So what about a new release to get things going?

[bastibe]

Do you think this should be a 0.9.1 or a 0.10.0?

Sorry for the slow rate of updates. Life is busy right now.

[mgeier]

I don't have a strong opinion on that as long as we are still below 1.0, either option seems fine to me.

We should probably try to make releases not such a big deal, e.g. by using a script such as https://github.com/bastibe/PySoundCard/blob/master/build_wheels.sh or https://github.com/spatialaudio/python-sounddevice/blob/master/make_dist.sh to speed up the process.

Shall I try to create such a script?

It probably also helps to make a little checklist, like I did at the end of this file: https://github.com/sfstoolbox/sfs-python/blob/master/CONTRIBUTING.rst?

Is there anything else I can do to help?

[bastibe]

That script is exactly what I am still using (once a year). I would be grateful for any assistance in this regard.

A CONTRIBUTING.rst would be a great idea, too--although its contents should probably be discussed in a pull request. In particular, I would like to include something like

However, please be aware that this is a hobby project of mine that I am developing for free, and in my spare time. While I try to be as accomodating as possible, I can not guarantee a timely response to issues. Publishing Open Source Software on Github does not imply an obligation to fix your problem right now. Please be civil.

(this is a quote from one of my other projects and would of course have to be changed).

Just a heads-up, though: I'm expecting a baby in the next few days, so my response time might be even longer than usual.

[mgeier]

Wow, I wish you a lot of fun in your first days of fatherhood!

We already have a CONTRIBUTING.rst (since #66), feel free to add your text there. TBH, I don't really like the text because it sounds a bit condescending, but it's up to you.

If you use one of those scripts, we should probably copy it to the repo?

[bastibe]

We already have a CONTRIBUTING.rst (since #66), feel free to add your text there.

Right, sorry about that. I didn't look into this much.

TBH, I don't really like the text because it sound a bit condescending, but it's up to you.

As I said, I wouldn't want to add that text verbatim, just something to a similar effect. I do get a bit of flak on social media whenever we push updates, and it is very annoying. Ever since I added a text like this to my other repos, responses have been more civil. I guess people expect commercial-grade support if they see commercial-grade software and documentation.

If you use one of those scripts, we should probably copy it to the repo?

I thought I used the script you linked to, but apparently I was wrong (apparently I was wrong a lot in that last post). Here's the actual script I use:

#!/usr/bin/env fish

rm dist/*.whl

rm -r build
set -xg PYSOUNDFILE_PLATFORM darwin
python setup.py bdist_wheel upload

rm -r build
set -xg PYSOUNDFILE_PLATFORM win32
set -xg PYSOUNDFILE_ARCHITECTURE 32bit
python setup.py bdist_wheel upload

rm -r build
set -xg PYSOUNDFILE_PLATFORM win32
set -xg PYSOUNDFILE_ARCHITECTURE 64bit
python setup.py bdist_wheel upload

rm -r build
set -xg PYSOUNDFILE_PLATFORM noplatform
set -xg PYSOUNDFILE_ARCHITECTURE noarch
python setup.py bdist_wheel upload
python setup.py sdist upload

I then run this script twice, while renaming "PySoundFile" to "SoundFile". But it's an ugly hack. I don't like how this script doesn't use twine, and how it doesn't automate the package renaming process, and how it's specific to my shell (fish). That's why I haven't uploaded it to the repo.

Speaking of which, do you have an idea how to deprecate "PySoundFile" without too much breakage?

[tgarc]

what about using cibuildwheel for releases?

[bastibe]

Wow, that sounds cool! This would be awesome!

I wouldn't want to automate the PyPi upload, though.

[tgarc]

Ah, I forgot you guys are bundling the libsndfile library in which makes things trickier...Anyway, I don't foresee having time for this in the near future so if you could hobble along with the current script to make the next release that would be much appreciated :D

[bastibe]

OK, the new release should be online now. Could you check if it works right?

Edit:

Something seems to be wrong, at least on macOS if I don't have libsndfile installed:

>>> import soundfile
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/bb/Projects/pysoundfile/soundfile.py", line 162, in <module>
    __libsndfile_version__ = _ffi.string(_snd.sf_version_string()).decode('utf-8', 'replace')
ffi.error: symbol 'sf_version_string' not found in library '<None>': dlsym(RTLD_DEFAULT, sf_version_string): symbol not found

It seems to work fine on Windows.

I have pulled the release from PyPI for that reason.

Find attached the wheels in question: Wheels.zip

I'd be grateful for help. Maybe the libsndfile binaries are outdated? Sorry but my time is extremely limited at the moment, so I might not be able to respond quickly.

[tgarc]

unfortunately I don't have a mac for testing...

It's confusing that cffi is reporting not found in library '<None>'. None usually means stdlib in cffi land.

It looks like sf_version_string was added in ee663d which was before the 1.0.20 release (May 14 2009) so it shouldn't be an issue with the binaries. Is it possible that there is a very old libsndfile installed on the test system which is getting loaded instead?

[mgeier]

I don't have a Mac either, but I have a possible lead:

I tried ctypes.util.find_library() on Linux with some nonsense string that doesn't exist as a library and it returns None instead of raising an exception!

Probably on macOS the behavior is the same?
And probably on Windows it does throw and therefore everything works as expected?

[mgeier]

It turns out that find_library() is actually supposed to return None: https://docs.python.org/3/library/ctypes.html#finding-shared-libraries

I guess the difference is that ffi.dlopen(None) throws on Windows and doesn't on macOS?