I’ve decided to use npm as means of distributing binaries for my github-agent little software. What do you think about this choice, how bad is it? Seems like not a bad option for little tools written in Haskell where you don’t want to spend too much time wrestling with snap/flatpak/deb/brew stuff.
I stole the scripts from the Elm project.
A bit strange for non-js project, github release binaries would be for me enough.
Regarding binaries, Facebook does this all the time (thesee are mostly OCaml-Binaries, but js-related), with bucklescript/reason and flow.js. And they use Packagist (PHP registry) for Hacklang projects (but are working on their own package manager)…
You mean the version, assets or something else? For version, 0.1.0.0 doesn’t work with npm. For assets, I agree, I’ve used one Elm has but would prefer something mentioning the program.
Names like pandoc-2.8.1-linux-amd64.tar.gz or github-agent-1.1.0-linux-x86_64.gz are more common than binary-for-linux-64-bit.gz.
I see. Agreed, will plan for the change in future.
@belka While we’re on this subject, is there a tool that allows easy packaging of Haskell projects into archives of a such format for various platforms including Linux, macOS and Windows? Or at least some blog post or guide about what these archives should contain except the binary itself. I noticed that such GItHub releases are common, for example, in Rust world. But I’d love to know best-practices regarding GitHub releases 
I mean, I wouldn’t use npm because it’s not terribly secure.
Sometimes in the past I’ve supplied bash scripts to users, though that has problems.
If you have a binary, I think what’s normally done is distributing various archives with the OS/architecture in the filename.
Unfortunately I have no idea, I’ve never used these GitHub archives for my own projects. I suppose people, who deploy them automatically, use GitHub API. You can then package your artifacts as part of your CI/CD pipeline and upload them using GitHub API. I think I saw some libraries for working with the old, REST-based, GitHub API on Hackage, but I’m not sure if there is something for the new, GraphQL-based API.
As for format, I don’t think there are any best-practices; every project is different. A few D projects, I was working on, just build a statically linked binary, compress and upload it. But for some reason they use .tar.gz but it shouldn’t be needed, if it is a single binary, just gzip it (without tar).
I think it’s not a bad idea. I actually wonder why still no one has pushed for an universal package manager which supports all programming languages. I havy many multi language projects and it’s pretty annoying if f you have to maintain several package files and so on. I guess GitHub’s https://github.com/features/packages is heading in this direction …
You mean package registry/repository? Besides GitHub Packages there are projects like jfrog artifactory (commercial). It supports php composer, npm, docker, ruby gems, maven… and custom layouts. Maven is mostly known in Java, I think, but also D’s package manager, dub, supports maven repositories. So there are definitely a few of them.
As for package managers, it’s probably difficult to bring a completely new solution, because each language has its own established infrastructure, that is often mature and well-documented; and it is almost impossible to compete with all of them. Nix allows to build packages from different languages, but it’s kind of difficult, requires know-how and workarounds to work with ruby, js, php packages.