Live data from Hacker News

Show HN: WAPM – Package Manager for WebAssembly

wapm.io

21–30 of 82 posts

Re: Show HN: WAPM – Package Manager for WebAssembly

#21
post #9

Why a new package manager? Why not port an existing well-designed generic package manager such as Nix? Making a new package manager is very expensive in terms of developer times - developers have to learn yet another new thing to use your platform. Can you justify this? Edit: For example, as matthewbauer commented below, Nix can support WebAssembly as a compilation target: https://github.com/NixOS/nixpkgs/pull/56555

Which general purpose package manager works correctly on Windows (not WSL, actual Windows) and Linux? Cross-platform is more important than not creating another package manager. I think a far more interesting question is, does the package repository support falling back to e.g. curl. That would allow those who don't want another package manager to still use the registry.

You should distinguish between "can run on Windows" and "can manage Windows software as packages". Most package managers could probably run fine on Windows; at worst they could use cygwin or, indeed, WSL. Managing Windows software is much harder, but isn't necessary: This is a package manager for WebAssembly packages, not Windows packages or Linux packages.

And anyway, wasmer itself doesn't even support Windows.

Re: Show HN: WAPM – Package Manager for WebAssembly

#22

I like Wasmer, but I very much dislike the idea of another major package repository being owned and operated by a commercial entity. They seem like good people doing valuable work now, but that doesn't tell us very much about who the company will be in five or ten years. I've grown uncomfortable with NPM being operated by NPM Inc instead of The Node.js Foundation, but it's a hard thing to change once it's established…

I completely understand your concerns, especially given the issues that NPM had lately. We are an open-source focused company and our success is tightly tied to the success of our open-source solutions. Here are some of the things that we are doing in order to resolve (or minimize) the concerns: * Completely open API to retrieve the registry data (it's a work in progress, but our GraphQL API is open to everyone to us…

Thanks! This is a good start.

Do you have ideas on how you will make the governance of the registry open? Who will make important decisions around policies, and how will they be made? I personally find this to be the core reason I find it hard to use startup-run package registries.

Re: Show HN: WAPM – Package Manager for WebAssembly

#25

Hi HN! We have also published an article to showcase wapm: https://medium.com/wasmer/announcing-wapm-the-webassembly-pa... Would love to hear your thoughts!

Hello,

1. Package managers are very hard! The same problems wrt dependency resolution pop up again and again. Whatever you do, I recommend uhm, copying whatever Yehuda et al did for Ruby, Rust, Yarn, i.e. bundler/cargo/yarn

There's lots of prior art out there, and a few days of reading can save you months of terrible effort! Here's one example but there's loads more out there https://yehudakatz.com/2016/10/11/im-excited-to-work-on-yarn...

2. Namely, I don't see any lock files! I didn't look very hard. But get yourself some lockfiles. I also can't stress this enough.

3. Packaging signing really needs to be baked in from the get go, re: https://news.ycombinator.com/item?id=19733085).

Good luck!

Re: Show HN: WAPM – Package Manager for WebAssembly

#26
post #18

Earlier quoted context omitted.

Signed packages are useful, but still don't solve the problem. One fairly simple thing you can do to improve this would be to include build scripts as part of the package, and allow people to run those build scripts through wapm. The exact versions of any involved tools will need to be recorded too, but since there arent too many ways to generate wasm blobs yet, this shouldnt be too out there. Eventually it would be…

Yeah, instructions onto how to build the package would be highly valuable. Environments where binaries are very backwards compatible (which itself is a good thing!) lend themselves to discarding abilities about how to build something. You could quickly land in a situation where you need to recompile some particular binary for some reason but figuring out how to compile it is really hard. Like how Microsoft fixed a vu…

Yes, definitely source+build instructions should be uploaded rather than binaries.

You can still support proprietary software by just uploading the binaries as source (and maybe doing some build-process to adapt it to the packaging format)

Re: Show HN: WAPM – Package Manager for WebAssembly

#28

I like Wasmer, but I very much dislike the idea of another major package repository being owned and operated by a commercial entity. They seem like good people doing valuable work now, but that doesn't tell us very much about who the company will be in five or ten years. I've grown uncomfortable with NPM being operated by NPM Inc instead of The Node.js Foundation, but it's a hard thing to change once it's established…

When I proposed package management for web assembly in 2015 I suggested that it should be a fully distributed system. https://github.com/WebAssembly/design/issues/320

Re: Show HN: WAPM – Package Manager for WebAssembly

#29
post #26
post #18

Earlier quoted context omitted.

Yeah, instructions onto how to build the package would be highly valuable. Environments where binaries are very backwards compatible (which itself is a good thing!) lend themselves to discarding abilities about how to build something. You could quickly land in a situation where you need to recompile some particular binary for some reason but figuring out how to compile it is really hard. Like how Microsoft fixed a vu…

Yes, definitely source+build instructions should be uploaded rather than binaries. You can still support proprietary software by just uploading the binaries as source (and maybe doing some build-process to adapt it to the packaging format)

Definitely, proprietary software should be supported. You could either let developers upload the binary directly, or just not offer sources to download for users, optionally deleting them after they have been built.

Debian has developed an amazing set of standards for software repositories which I think should be applied universally to all package management ecosystems that want to have open source at their core.

E.g. they require that the source code has to be actual source code, aka "preferred form of modification" and not something minified. They also have separate repositories for proprietary and DFSG-free software, allowing users to choose whether they want to use proprietary software or not. Also, they run their builds without internet access, so the source code (as well as the dependencies tracked by the system) is actually everything needed.

Re: Show HN: WAPM – Package Manager for WebAssembly

#30

I love WebAssembly/WASI, but I'm concerned about us repeating the mistakes of the past. How does the dependency model work? Can I safely install parallel streams of software? Does it support unprivileged installation? Is the installation stateless (no scriptlets/lifecycle scripts)?

> Is the installation stateless (no scriptlets/lifecycle scripts)?

I feel like the reason `npm`/the node.js ecosystem has these is because... as soon as you want to do anything serious, you need them.

How else do you build native modules across different platforms, run initial post-installation configuration scripts, etc.?

Post reply on HN