6 ms·

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

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. We should hesitate to support the establishment of another community package manager by a for-profit company.

syrusakbary 7y ago
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 use: https://registry.wapm.io/graphql https://registry.wapm.io/graphql ) * De-centralized hosting of the packages (news to come soon!)
- yuvipanda 7y ago
  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.
  - deleted 7y ago
    [deleted]
  - syrusakbary 7y ago
    We are starting to research on governance, but to date nothing is defined (since we have just launched). However, I would love to follow up with you personally to make sure we make the right choices from the start. Can you write me an email to syrus@wasmer.io so we continue the conversation there?
- badsectoracula 7y ago
  > our success is tightly tied to the success of our open-source solutions It is not obvious from your website, so if your success is tied to your open source solutions - as you say - how do you actually make money?
- jake_the_third 7y ago
  > De-centralized hosting of the packages (news to come soon!) Is the index also going to be changeable? Will I be able to completely avoid your servers if I wanted to?
- hobofan 7y ago
  > * De-centralized hosting of the packages (news to come soon!) Given that "integration in package managers" is a big point in the IPFS 2019 Roadmap[0], I'm going to guess those two are related. [0]: https://blog.ipfs.io/78-ipfs-2019-roadmap/ https://blog.ipfs.io/78-ipfs-2019-roadmap/
- intertextuality 7y ago
  How are you going to make money? How are you going to fund offices in CA + developers + the operating costs of the registry? I really don’t think a private entity should be running a registry. Ruby is just about the only example of a registry handled correctly - via the community and non-profits.
  - fnord123 7y ago
    Ruby is an example of it done so wrongly that other languages are chopping their hands off to avoid making the same mistakes. Apparently there is a namespacing in the Ruby repository and Github started automatically pushing every fork to the repo as a gem. So fnord123/cool-project would also have intertextuality/cool-project just because you forked it. And it was a nightmare to figure out which one was the right one. Now the Rust team avoids namespaces like the devil citing the Ruby issue even though there are people begging to have something like Java's scheme since it works. So really, Java is just about the only example of a registry handled correctly - distributed and namespaced and signed.
    - intertextuality 7y ago
      Sigh. There is a difference between architectural design (namespacing), and funding income. I am -not- discussing the software architecture of rubygems here, please don't start a bikeshed with that. Rubygems is a shining example of how non-profits and the ruby community fund rubygems, not yet-another-californian-company-without-clear-income-plans. Also, there's no need for highly embellished language ("languages are chopping their hands off").
      - fnord123 7y ago
        Fair enough. I jumped the gun because I agree with your actual point and then I moved onto the sliver where it's possible to disagree.
k__ 7y ago
Yes, at least they could host it on IPFS or dat.
ilaksh 7y ago
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 https://github.com/WebAssembly/design/issues/320
treve 7y ago
It seems like whenever a new language pops up there's a race to build all the standard ecosystem tooling.
thefounder 7y ago
WASM should use something like GO where you can use any git/mercurial/bazaar repository to fetch the packages and 3rd party services(i.e godoc.org) to index them.
- yuchi 7y ago
  Not a good idea. Semver range on dependency plus lock file is the holy grail of dependency management (ask Maven people) and cannot be done with git (cvs) registries. You’re tied to pinned versions (lockfile) only.
  - krapp 7y ago
    Don't let the perfect be the enemy of the good. WASM is barely off the ground and already we have a company trying to establish itself as the authoritative package manager and registry host the way NPM has become for javascript. It's more important to prevent centralization by demanding that there be no authority other than the end user, and by building tools to enforce those expectations, than to have a "holy grail" of dependency management be controlled by a single corporate interest. I'd rather WAPM be built with their registry as a default option, but designed to be completely agnostic regarding registries or repositories. I'd like to use it and never have to touch their servers if I don't want to.
    - yuchi 7y ago
      > Don't let the perfect be the enemy of the good We’re not talking about good vs perfect. We’re talking about «a big ball of hairy non-compatible dependencies» vs «an upgradeable declarative definition of dependencies». > I'd rather WAPM be built with their registry as a default option, but designed to be completely agnostic regarding registries or repositories. That’s how npm works, yet you don‘t see git/vcs dependencies very often. That’s because they don’t work.
      - asdkhadsj 7y ago
        In fairness, the OP mentioned Go, but you're dropping details. Ie, in Go it works just fine but it is more than just plain Git, there is a dependency file. Semver works with the repo itself based on repo tags. I think you're not arguing against what the spirit of OPs post meant, aka the "like Go" part. Like Go does work, Go is using it and it includes a lock file just like you mentioned. There are definitely downsides to using repos as dependency resolution hosts, but none of that in my view is what you mentioned. Lockfiles in repos are not complex or unsolvable, I'm not sure why you pit them as such - again, look at Go. If you want to talk about why repos shouldn't be used, imo, talk about the volatility of them. A de/centralized host specially targeted at distributing source seems to have less volatility in existence when compared to git repos. It's rare to have packed disappear from Cargo (Rust's package manager), but I've had it happen multiple times in Go.
Leace 7y ago
Agreed. I wonder why package managers can't follow Go's lead in re-using DNS system for packages and then offering a service that just indexes what is available. Example indexing service: https://godoc.org/ https://godoc.org/ Example package: https://godoc.org/go.uber.org/zap https://godoc.org/go.uber.org/zap
BubRoss 7y ago
Julia uses git and GitHub. This was a stroke of brilliance until microsoft bought GitHub. It still will probably be a clever decision, GitHub could be phased out in favor of another git site.

syrusakbary 7y ago

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 use: https://registry.wapm.io/graphql https://registry.wapm.io/graphql ) * De-centralized hosting of the packages (news to come soon!)

yuvipanda 7y ago
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.
- deleted 7y ago
  [deleted]
- syrusakbary 7y ago
  We are starting to research on governance, but to date nothing is defined (since we have just launched). However, I would love to follow up with you personally to make sure we make the right choices from the start. Can you write me an email to syrus@wasmer.io so we continue the conversation there?
badsectoracula 7y ago
> our success is tightly tied to the success of our open-source solutions It is not obvious from your website, so if your success is tied to your open source solutions - as you say - how do you actually make money?
jake_the_third 7y ago
> De-centralized hosting of the packages (news to come soon!) Is the index also going to be changeable? Will I be able to completely avoid your servers if I wanted to?
hobofan 7y ago
> * De-centralized hosting of the packages (news to come soon!) Given that "integration in package managers" is a big point in the IPFS 2019 Roadmap[0], I'm going to guess those two are related. [0]: https://blog.ipfs.io/78-ipfs-2019-roadmap/ https://blog.ipfs.io/78-ipfs-2019-roadmap/
intertextuality 7y ago
How are you going to make money? How are you going to fund offices in CA + developers + the operating costs of the registry? I really don’t think a private entity should be running a registry. Ruby is just about the only example of a registry handled correctly - via the community and non-profits.
- fnord123 7y ago
  Ruby is an example of it done so wrongly that other languages are chopping their hands off to avoid making the same mistakes. Apparently there is a namespacing in the Ruby repository and Github started automatically pushing every fork to the repo as a gem. So fnord123/cool-project would also have intertextuality/cool-project just because you forked it. And it was a nightmare to figure out which one was the right one. Now the Rust team avoids namespaces like the devil citing the Ruby issue even though there are people begging to have something like Java's scheme since it works. So really, Java is just about the only example of a registry handled correctly - distributed and namespaced and signed.
  - intertextuality 7y ago
    Sigh. There is a difference between architectural design (namespacing), and funding income. I am -not- discussing the software architecture of rubygems here, please don't start a bikeshed with that. Rubygems is a shining example of how non-profits and the ruby community fund rubygems, not yet-another-californian-company-without-clear-income-plans. Also, there's no need for highly embellished language ("languages are chopping their hands off").
    - fnord123 7y ago
      Fair enough. I jumped the gun because I agree with your actual point and then I moved onto the sliver where it's possible to disagree.

k__ 7y ago

Yes, at least they could host it on IPFS or dat.

ilaksh 7y ago

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 https://github.com/WebAssembly/design/issues/320

treve 7y ago

It seems like whenever a new language pops up there's a race to build all the standard ecosystem tooling.

thefounder 7y ago

WASM should use something like GO where you can use any git/mercurial/bazaar repository to fetch the packages and 3rd party services(i.e godoc.org) to index them.

yuchi 7y ago
Not a good idea. Semver range on dependency plus lock file is the holy grail of dependency management (ask Maven people) and cannot be done with git (cvs) registries. You’re tied to pinned versions (lockfile) only.
- krapp 7y ago
  Don't let the perfect be the enemy of the good. WASM is barely off the ground and already we have a company trying to establish itself as the authoritative package manager and registry host the way NPM has become for javascript. It's more important to prevent centralization by demanding that there be no authority other than the end user, and by building tools to enforce those expectations, than to have a "holy grail" of dependency management be controlled by a single corporate interest. I'd rather WAPM be built with their registry as a default option, but designed to be completely agnostic regarding registries or repositories. I'd like to use it and never have to touch their servers if I don't want to.
  - yuchi 7y ago
    > Don't let the perfect be the enemy of the good We’re not talking about good vs perfect. We’re talking about «a big ball of hairy non-compatible dependencies» vs «an upgradeable declarative definition of dependencies». > I'd rather WAPM be built with their registry as a default option, but designed to be completely agnostic regarding registries or repositories. That’s how npm works, yet you don‘t see git/vcs dependencies very often. That’s because they don’t work.
    - asdkhadsj 7y ago
      In fairness, the OP mentioned Go, but you're dropping details. Ie, in Go it works just fine but it is more than just plain Git, there is a dependency file. Semver works with the repo itself based on repo tags. I think you're not arguing against what the spirit of OPs post meant, aka the "like Go" part. Like Go does work, Go is using it and it includes a lock file just like you mentioned. There are definitely downsides to using repos as dependency resolution hosts, but none of that in my view is what you mentioned. Lockfiles in repos are not complex or unsolvable, I'm not sure why you pit them as such - again, look at Go. If you want to talk about why repos shouldn't be used, imo, talk about the volatility of them. A de/centralized host specially targeted at distributing source seems to have less volatility in existence when compared to git repos. It's rare to have packed disappear from Cargo (Rust's package manager), but I've had it happen multiple times in Go.

Leace 7y ago

Agreed. I wonder why package managers can't follow Go's lead in re-using DNS system for packages and then offering a service that just indexes what is available. Example indexing service: https://godoc.org/ https://godoc.org/ Example package: https://godoc.org/go.uber.org/zap https://godoc.org/go.uber.org/zap

BubRoss 7y ago

Julia uses git and GitHub. This was a stroke of brilliance until microsoft bought GitHub. It still will probably be a clever decision, GitHub could be phased out in favor of another git site.