4 ms·

Let's fix NPM with IPM – Immutable Package Manager

24 points by reimertz 11y ago

doragcoder 11y ago
More Go centric, but they are similar. So there may be some ideas that could cross-pollinate. https://github.com/artktec/gopkgr https://github.com/artktec/gopkgr
bcheung 11y ago
I wonder if it makes sense to combine some kind of blockchain technology.
- reimertz 11y ago
  I like the idea and I couldn't agree more. Would be awesome if each individual package could be verified, maybe even stored, using the block chain. If you have some time, please add an issue on the repo and start the discussion over there.
ZoFreX 11y ago
How does this fix the issue? Even if you think the Kik trademark claim was invalid... what happens when a valid trademark claim arrives?
- dandelany 11y ago
  Ideally, names could still change hands, but it would require a major version bump. So I publish 'google-lib' 1.0.0, Google files a trademark claim and is given publishing rights on the 'google-lib' package, but only for versions >=2.0.0. If a company still goes after you for hosting the archived code, that's when you make a legal stand and try to get EFF involved or something - because there's zero case for "reasonable likelihood of [trademark] confusion" over a deprecated version of a package which is only available via 'npm install'. I would expect this to never/rarely happen. The harder question is what to do when you get a valid copyright claim, ie. when someone publishes code that wasn't theirs to publish. I think in this case, immutability doesn't really work, and you'd have to retroactively remove all versions. This should also be fairly rare, especially since so many packages are <500 lines of code.
  - reimertz 11y ago
    This is an issue that we don't have a clear solution or path for right now but love that you guys spend some thinking about how it could be solved. Super valuable to us. :) I would appreciate if one of you added this as an issue at the repo with any ideas and solutions you come up with.
  - vskarine 11y ago
    That's actually sort of how NPM works currently, they mentioned that that's exactly how they would solve kik situation, by giving them new version of the package: http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm "Had Azer taken no action, Kik would have published a new version of kik and everyone depending upon Azer’s package could have continued to find it."
    - spriggan3 11y ago
      > In a global namespace for unscoped modules, collisions are inevitable. why does npm works with a global namespace to begin with ? don't they understand that's the root of the issue ?

24 points by reimertz 11y ago

More Go centric, but they are similar. So there may be some ideas that could cross-pollinate. https://github.com/artktec/gopkgr https://github.com/artktec/gopkgr

bcheung 11y ago

I wonder if it makes sense to combine some kind of blockchain technology.

reimertz 11y ago
I like the idea and I couldn't agree more. Would be awesome if each individual package could be verified, maybe even stored, using the block chain. If you have some time, please add an issue on the repo and start the discussion over there.

ZoFreX 11y ago

How does this fix the issue? Even if you think the Kik trademark claim was invalid... what happens when a valid trademark claim arrives?

dandelany 11y ago
Ideally, names could still change hands, but it would require a major version bump. So I publish 'google-lib' 1.0.0, Google files a trademark claim and is given publishing rights on the 'google-lib' package, but only for versions >=2.0.0. If a company still goes after you for hosting the archived code, that's when you make a legal stand and try to get EFF involved or something - because there's zero case for "reasonable likelihood of [trademark] confusion" over a deprecated version of a package which is only available via 'npm install'. I would expect this to never/rarely happen. The harder question is what to do when you get a valid copyright claim, ie. when someone publishes code that wasn't theirs to publish. I think in this case, immutability doesn't really work, and you'd have to retroactively remove all versions. This should also be fairly rare, especially since so many packages are <500 lines of code.
- reimertz 11y ago
  This is an issue that we don't have a clear solution or path for right now but love that you guys spend some thinking about how it could be solved. Super valuable to us. :) I would appreciate if one of you added this as an issue at the repo with any ideas and solutions you come up with.
- vskarine 11y ago
  That's actually sort of how NPM works currently, they mentioned that that's exactly how they would solve kik situation, by giving them new version of the package: http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm "Had Azer taken no action, Kik would have published a new version of kik and everyone depending upon Azer’s package could have continued to find it."
  - spriggan3 11y ago
    > In a global namespace for unscoped modules, collisions are inevitable. why does npm works with a global namespace to begin with ? don't they understand that's the root of the issue ?