Best way to distribute a FOSS tool in 2023?
source link: https://lobste.rs/s/wk9qye/best_way_distribute_foss_tool_2023
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Best way to distribute a FOSS tool in 2023?
Let’s say you are building a simple command-line utility tool for software engineers with
What’s the best way to distribute it in 2023?
I am relatively agnostic to the language I would write in.
The options that I have looked at
Have you looked at Flatpak? https://flathub.org/ for example. You can also host your own, but flathub is the de facto standard.
One correction: Homebrew is not Mac-only, as it also supports Linux.
However, to answer your question more directly: The goal should be to make it as easily-packable and portable as possible, which means no crazy build system (I always use POSIX make with a Makefile and a config.mk-file with a configure-script that simply modifies the variables in config.mk for a given target system (see here), but your mileage may vary) and reasonable dependencies. Use semantic versioning, especially for libraries.
For hosting: I would recommend setting up your own website with your own git or gitlab instance where you set version as tags and publish tarballs with hashes as repository-states at a given tag. It is relatively cheap to do that. As a backup, you can set up mirror repositories on GitHub and so forth, and it will work just fine, given each tag will also be mirrored as a “release”.
Over the years I have learnt that you do not get around working with package maintainers. Ask them what you can improve to make your tool easier to package and actively send pull requests/patches to package your tool in popular distributions. Of all distributions, Debian/Ubuntu is the most difficult of all to get into and almost impossible without inside help, whereas other distributions make it very easy.
I personally do not include version checks into my tools, but it can be done simply enough if you can live with the extra cruft in your binary (network code, parsing, etc.). In C, I would have a Makefile that contains a variable VERSION that is passed to the C-preprocessor as -DVERSION=$(VERSION), which in turn can be used in the code to compare it against the current online version.
Regarding packaging again: I have never met an unkind package maintainer and the work they do is mostly unthanked for. One e-mail straight out asking to be included in the package sources often does wonders. :)
The topic of Windows comes up here and there: I would target MinGW-W64 and not even start trying to port to MSVC. The advantage with MinGW-W64 is that you can use the usual POSIX tools like make and, compared to Cygwin, obtain true native binaries.
-
As a package maintainer, this is the right answer. Windows generally has other needs, but for all the nixes, you can go through the front door of package management and offload the work to others.
That is, so long as you do pretty standard things to build. If you’re writing go, make sure go get works in your repo. If you are expecting to build from a git checkout, make it possible to fake whatever values you are going to read from git. If you are writing something autotools, use autotools. If you are generating things with a custom compiler, at least bundle those artifacts in a tarball with the rest of your source so maintainers don’t need to find the right version of that compiler (see: https://github.com/hashicorp/vault/issues/7350 for an example of maintainers pleading with upstream to do this).
Just do as package managers expect and you’ll be on every platform you might use and several others besides.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK