Release binaries on github releases

[ankith26]

Greetings!
First of all, it's nice to see that you've taken efforts to get portmidi going again, that's great news!
I'm one of the contributors to the pygame project, and we make use of portmidi to provide some midi functionality in the pygame library.
Having releases on github would make things easier for users of the portmidi library like us, our build scripts (especially on windows) could directly pull binaries from github releases, and save some buildconfig and build time on our end.
It would be easy to automate with github actions CI after #11 is merged. On release, the CI could just upload binaries for supported platforms, that would save manual work on releases

I'd be happy to help in setting up these things, if needed :)

[Be-ing]

#11 already uploads GitHub Actions artifacts. However, downloading binaries built by other people in your build process isn't a great idea. That is how you get into situations where nobody knows how to build from source anymore.

[rbdannenberg]

It seems reasonable to me, especially for Python, where users may not even have installed C/C++ development environments, to release pre-compiled libraries. It seems to me that Python has its own install system and way of doing things, so maybe this is more of a "PortMidi for Python" thing that should be associated with another repo, e.g. PortMidi/pm_python is pretty much just a place-holder now. I think users want a complete Python library to be imported into Python, not just a place to get a compiled portmidi library. I guess you want compiled libraries as part of the process to build a Python-ready library? Regardless, it seems that even though they are small, it would be best to keep binaries separated from source releases, and not even in git, which is not made for binaries. If #11 already does what you want, great, I've just been trying to get a working release first before adding more complexity. If not, what would be best?

[ankith26]

Hmmm, I think this issue is more generic than portmidi on python. Generally this wouldn't be much of a problem on mac/linux, where package managers are much more commonplace than windows (yes I know windows package managers exist, it's just that they are not widely used).
I see most pure C/C++ projects tend to provide windows release binaries because of the same reason, so as an average windows user, it's more convenient to have some downloadable zipped binaries to download and set things up. It's not the most streamlined process among other stuff, but most windows users are better accustomed to this than using a package manager or building deps from source. These binaries need not necessarily be on github releases, you can choose what works out best for you in terms of maintenance, although most projects these days have github releases with binaries

[rbdannenberg]

My advice has always been to use static linking, which eliminates separate installation and version problems at the cost of around 45KB of disk space per PortMidi application, which seems like rounding error these days.

But I can't dictate how people build and release their code, so I'm open to changes that support other processes (even though I can't implement or test them myself).

[ankith26]

Hmm yeah, static linking seems to be a good idea on compact libs like portmidi

[rbdannenberg]

I think there's no much demand for precompiled binaries, and I don't have faith that I could properly document, test and maintain them (e.g. do they get built from the head? - that would be bad - do they get built from the latest release? - do we then set up a history page, naming scheme, and multiple downloads for different versions and systems?) Anyone that wants to do this right has my support, but I think it's safer to do nothing than put up stuff that will lure people into downloading obsolete or untested binaries when the source code releases are getting all the love and care.