Replace travis with GitHub for running CI jobs

[hagenw]

Since some time we can now run CI jobs directly with Github. I like that solution as you don't need to use an external service. I would propose to switch our tests to Github as well.

In addition, this proposes to remove support for Python 3.5, which would bring the following benefits for writing the code:

• dictionaries behave in a more predictable way, as they are ordered since Python 3.6
• we can use f'{variable} in strings'

/cc @mgeier

[hagenw]

BTW, the Github workflows can even be used to automate the package release process, e.g. for every tag build wheel upload it to pypi.org and create a release on Github from the CHANGELOG.

[mgeier]

Thanks, this is great!

I agree with removing Python 3.5 support, but you should reflect this in setup.py.

BTW, the Github workflows can even be used to automate the package release process, e.g. for every tag build wheel upload it to pypi.org and create a release on Github from the CHANGELOG.

I think uploading the package manually isn't a lot of work, but why not reduce the amount of work even more!

How would the PyPI authorization work?

Anyway, I think this should happen in a separate PR.

[hagenw]

Thanks, this is great!

I agree with removing Python 3.5 support, but you should reflect this in setup.py.

I removed it from setup.py

BTW, the Github workflows can even be used to automate the package release process, e.g. for every tag build wheel upload it to pypi.org and create a release on Github from the CHANGELOG.

I think uploading the package manually isn't a lot of work, but why not reduce the amount of work even more!

If you have a lot of packages to maintain and different users that should be able to create releases it is helpful. If you only do a release once a month/year, it's indeed not really needed.

How would the PyPI authorization work? You can store secrets in your personal or organisation account and use those to authenticate.

Anyway, I think this should happen in a separate PR.

Yes.

[mgeier]

How would the PyPI authorization work?

You can store secrets in your personal or organisation account and use those to authenticate.

Yes, but who's secrets? Would we need an organization account on PyPI?

I forgot, but we actually have one: https://pypi.org/user/spatialaudio/

Would we generate a secret from this account?

[hagenw]

How would the PyPI authorization work?

You can store secrets in your personal or organisation account and use those to authenticate.

Yes, but who's secrets? Would we need an organization account on PyPI?

I forgot, but we actually have one: https://pypi.org/user/spatialaudio/

Would we generate a secret from this account?

Sounds reasonable. I'm not sure if you can see at https://pypi.org/project/sfs/0.6.0/ who did the actual publishing. Otherwise a private account would also work.

[mgeier]

I'm not sure if you can see at https://pypi.org/project/sfs/0.6.0/ who did the actual publishing.

I don't know. I didn't see any indication on the web page ...

Otherwise a private account would also work.

What do you mean by private account?

[hagenw]

Should have set personal PyPI account instead of private. For example at audeering we use the credentials of my PyPI account.

[mgeier]

OK, thanks.