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.

[mgeier]

Why is this explicitly limited to master?
Won't all (or at least most) PRs be from master?
I don't really have experience with non-master PRs, but I don't see a reason why to prohibit them. Is there?

[hagenw]

I think it stems from me trying to limit CI jobs, as for example in private repos you can have only some hundereds each month.
But you are right, we can maybe completely remove the limit here.

[hagenw]

I removed all limitations and the CI jobs should now be executed for every push / pull request.

[hagenw]

Now it will run all CI jobs twice for pull requests, one time for the push event, one time for the pull request. This might be not necessary, or would you prefer it this way?

[mgeier]

If you know a way to avoid the duplication, that would be great. But I think both things individually are very useful.

[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.