Looks like this wasn't built in response to the recent NPM drama but sounds like a perfect alternative.
IPFS providing the ability for permanent, signed content makes this great.
Gx: A package management tool built around IPFS
11–20 of 46 posts
Re: Gx: A package management tool built around IPFS
#12Developer here! i didn't expect to wake up to my github feed being destroyed by this. gx was originally a response to being frustrated with go's package management system, so i wrote gx and gx-go to handle go dependencies in a nice(ish) way. We made the decision to keep gx itself as agnostic and extensible as possible, package manager logic is largely the same across the board, so why not provide a nice base layer fo…
jbenet here. We're all very excited about the dev interest in gx and ipfs! thanks! we did not expect attention on it this soon! Please check it out, try it, and give us feedback!
Please know though that things are still super early, and very rough! We do not think our pkg mgment efforts are UX ready for end users who want something strictly better today. But they are ready for early adopters who want to think or hack on them with us. In fact, we are now self-hosting go-ipfs in gx! https://github.com/ipfs/go-ipfs
Something to bear in mind: we are building infrastructure you can rely on long term, with decentralization, flexibility, and futureproofing from the ground up. We want our protocols and tools to survive independent of fragile organizations or fragile routing. We can't take many shortcuts (like depending on centralizing agents), because we want something rock solid to last for decades. This means it takes us a lot longer to build high perf and high quality UX, because there's a lot more to do. More work, but it is all achievable. The rough edges will disappear as we improve the tooling. Even today, gx is amazingly simple and powerful, and already does much for dependability.
It's worth mentioning other package management tooling we're working on too:
* NPM + IPFS - https://github.com/diasdavid/registry-mirror and other repos. This is an effort to improve how NPM works with IPFS
* pacman + ipfs - https://github.com/ipfs/notes/issues/84 - this is a super rough way to show how to add ipfs support to a package manager through FUSE. it's not the best way, but it works!
* also, we We have LOTS in development and store for the package manager communities. It's a very exciting time. Please join us at https://github.com/ipfs/ipfs and #ipfs and #gx on freenode IRC. And, if anyone wants to work on "Hypermodular Programming" with us, see https://github.com/jbenet/random-ideas/issues/27 and ping me :)
Re: Gx: A package management tool built around IPFS
#13(I meant to mention this is an nodejs NPM replacement, specifically)
but i've learned it can do more than only solving npm replacement, very cool!
Re: Gx: A package management tool built around IPFS
#14In all this discussion of npm, I wonder how PyPi stacks up. Once I tried to fix an issue with the source distribution of one of my packages on PyPi and found that I could delete it just fine, but uploading a new file with the same name failed. I tried re-uploading the original sdist, but that failed as well. Apparently once it's gone it's gone. I eventually just uploaded a different format then quickly pushed a new v…
This is probably done for security: if a package gets removed it can't be replaced by something potentially malicious. In addition, people that have tied their version numbers would get alerted this way.
Re: Gx: A package management tool built around IPFS
#15In all this discussion of npm, I wonder how PyPi stacks up. Once I tried to fix an issue with the source distribution of one of my packages on PyPi and found that I could delete it just fine, but uploading a new file with the same name failed. I tried re-uploading the original sdist, but that failed as well. Apparently once it's gone it's gone. I eventually just uploaded a different format then quickly pushed a new v…
This is probably done for security: if a package gets removed it can't be replaced by something potentially malicious. In addition, people that have tied their version numbers would get alerted this way.
Yeah, but I think either I shouldn't be able to delete it in the first place or I should be able to upload the original package with an unchanged hash. The alternative is that anyone with an == dependency is now permanently broken.
Re: Gx: A package management tool built around IPFS
#16I'm really hoping someone adds an IPFS binary cache system for Nix/NixOS. (Nix already packages tons of Go/python/javascript/rust libraries and binaries)
I've wanted exactly this for ages. Would make reproducible builds and distributions simple.
Re: Gx: A package management tool built around IPFS
#17Let's say we adopt this. Cut to some small number of years in the future, and everyone is complaining about how dealing with 46-character-long opaque strings is terrible.
This is a great idea, but there's no mention of versioning. As a long-time advocate of what we now refer to as Semantic Versioning, I can't help but see this as a disaster waiting to happen.
Re: Gx: A package management tool built around IPFS
#18Let's say we adopt this. Cut to some small number of years in the future, and everyone is complaining about how dealing with 46-character-long opaque strings is terrible. This is a great idea, but there's no mention of versioning. As a long-time advocate of what we now refer to as Semantic Versioning, I can't help but see this as a disaster waiting to happen.
The hash is the version. However, the extra information semantic versioning gives is missing of course.
Re: Gx: A package management tool built around IPFS
#19Let's say we adopt this. Cut to some small number of years in the future, and everyone is complaining about how dealing with 46-character-long opaque strings is terrible. This is a great idea, but there's no mention of versioning. As a long-time advocate of what we now refer to as Semantic Versioning, I can't help but see this as a disaster waiting to happen.
Excellent concerns! gx addresses both:
> Let's say we adopt this. Cut to some small number of years in the future, and everyone is complaining about how dealing with 46-character-long opaque strings is terrible.
Agreed. You can point gx to "repos" (/ipfs addresses that map (package, version) => /ipfs/... addresses. This lets you use simple names, and anyone can publish a repo.
see https://github.com/whyrusleeping/gx#repos
> This is a great idea, but there's no mention of versioning. As a long-time advocate of what we now refer to as Semantic Versioning, I can't help but see this as a disaster waiting to happen.
Sorry, this is a documentation failure rather than a feature failure: gx has semver built in and adheres to it today.
Re: Gx: A package management tool built around IPFS
#20Especially after all the NPM drama, I'd be really interested in a distributed package manager that:
(1) Validates that the specific revision of a package you're dependent on hasn't changed (i.e. checksum of the package stays the same), and
(2) On upgrade, validates that ownership of the package hasn't changed (i.e. package is signed by the same person), or that any change in ownership is authorized/authenticated and traceable to the author of the previous revision. Some sort of strong notion of identity would be essential here, too-- maybe something along the lines of Keybase.
This looks like it does #1 (by virtue of being based on a content-addressable filesystem), but it doesn't look like it tries to handle #2... objects and repos just "are"; they don't seem to carry ownership information with them. If I want to validate that I am, in fact, getting Express.js from the Node.js Foundation and not some complete stranger, I'm forced to trust whatever website I pulled the package or repository hash from.
(This identity/authentication issue isn't new-- for example, Apt solves it with GPG signing of repositories, and assume that the repository is taking responsibility for the safety of the content they're publishing. It doesn't seem to be something that these newer (less strictly-managed) tools seem to be concerned about, though-- npm, bower, homebrew, etc.)