Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An NPM installer #76

Open
MaybeJustJames opened this issue Feb 3, 2022 · 1 comment
Open

An NPM installer #76

MaybeJustJames opened this issue Feb 3, 2022 · 1 comment

Comments

@MaybeJustJames
Copy link
Owner

Being able to install via NPM would probably be nice and lower the barrier to using zephyr

@toastal
Copy link
Contributor

toastal commented May 11, 2022

Agreed*. In the past, we had to really jump through some hoops to get this binary into our environment--like Heroku. I had to build an asdf script to help get the binary locally to non-Nix users as well.

*Disagreements: while this does help some setups and team, in the larger scope, delivering binaries via NPM is kind of anti-pattern--and NPM not having checksums means it's not a reliable tool when you could snipe an email and publish malicious code; in newer contracts/teams, we've avoided NPM as much as possible. Really our setups should be robust enough that adding another binary isn't seen as an issue to overcome. PureScript is PureScript, a tool separate and not inside of the Node ecosystem (though in practice has a lot of overlap).

There's also a lot of caveats to consider::

  • what architecture is the user running
  • does that system have glibc or not (I put note in the README about this, failing once to get it in a Alpine Docker container and then later failing to just pull the binary into Nix/NixOS)

These are real problems that would need to be solved. One could go the route of compiling a staticly-linked binary with llvm + musl to get more portability on Linux, but macOS can't handle static binaries so what do you do? We see a loud bunch of ARM-based macOS users now demanding support while the ARM support on Linux and Windows exists but no one bothered to care. There's the BSDs... the list goes on. Making assumptions like isDarwin or isLinux is obviously myopic and NPM is not build to distribute binaries in a meaningful way like this so there's a lot of wheels to reinvent and hope to get right.


If it were me and I had infinite knowledge and time (lol), providing a flake.nix with nixpkgs.pkgsMusl and the like could go a long way--skipping NPM support altogether. Users of Nix could tap into this project with ease as an input and the CI could build/cross-compile a large swath of binaries for various architectures for delivering to everyone else and even containers could be built and the sorry folks using *-compose architectures as well. Everything here though applies to the state that Spago and even the PureScript compiler are in as well--which is the whole reason easy-purescript-nix has to exist, patchelfing the binaries and dynamically linking to where Nix keeps its libs. That's not to say parts of the idea couldn't be used piecemeal like #65.

Between Nix, static bins, and containers, a lot more of the deployment space would be covered than bothering with NPM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants