Author here. This is currently at the stage of an afternoon thought experiment, but I’m interested in your feedback and help!
Probably the most important open issue is that simple names aren’t a sufficient identifier with a decentralized registry: you need a URL. So once Crom learns how to save package metadata, it should probably map any specified short name (e.g., `d3-format`) into a full URL (https://github.com/d3/d3-format) to ensure stability.
Mutable releases are also a concern, but Crom could save the hash of installed packages so you’d know if anything changed. And of course, since it’s decentralized, you could still have third-party registries that make immutable copies, if that’s your thing.
As far as I know there are channels with nix-expressions (which are the package definitions), which are descriptions of how gather the source-code or binaries from specific URLs.
npm2nix for example only uses npm to gather the the packages from the registry, but uses Nix for all the other stuff. [0]
One of way of looking at Crom is that it provides a more convenient interface than a URL, yet without the centralization that comes from using names in a registry.
Crom helps you go from a name to a URL (via search heuristics), but it’s the URL that ultimately serves as the identifier. So, if you author a package.json with a name like “d3-format”, that gets expanded to a full URL, perhaps with interactive confirmation. (Or not, because it’s trivial to undo and redo.)
Also, unlike a URL to the ZIP file directly, a package URL in Crom supports semantic versioning: it refers to all versions of a project, and thus you can upgrade or specify a desired version range.
Reminds me of vim plugin managers like Vundle or NeoBundle. The way they work is you specify a package name and it uses a heuristic to figure out where to look. To steal from the Vundle README...
" The following are examples of different formats supported.
" Keep Plugin commands between vundle#begin/end.
" plugin on GitHub repo
Plugin 'tpope/vim-fugitive'
" plugin from http://vim-scripts.org/vim/scripts.html
Plugin 'L9'
" Git plugin not hosted on GitHub
Plugin 'git://git.wincent.com/command-t.git'
" git repos on your local machine (i.e. when working on your own plugin)
Plugin 'file:///home/gmarik/path/to/plugin'
" The sparkup vim script is in a subdirectory of this repo called vim.
" Pass the path to set the runtimepath properly.
Plugin 'rstacruz/sparkup', {'rtp': 'vim/'}
" Avoid a name conflict with L9
Plugin 'user/L9', {'name': 'newL9'}
It's one of those things that works so well you can just kind of forget about it once you get used to it, but you're not really locked in either.
7 comments
[ 2.9 ms ] story [ 27.3 ms ] threadProbably the most important open issue is that simple names aren’t a sufficient identifier with a decentralized registry: you need a URL. So once Crom learns how to save package metadata, it should probably map any specified short name (e.g., `d3-format`) into a full URL (https://github.com/d3/d3-format) to ensure stability.
Mutable releases are also a concern, but Crom could save the hash of installed packages so you’d know if anything changed. And of course, since it’s decentralized, you could still have third-party registries that make immutable copies, if that’s your thing.
npm2nix for example only uses npm to gather the the packages from the registry, but uses Nix for all the other stuff. [0]
[0]: http://sandervanderburg.blogspot.de/2014/10/deploying-npm-pa...
One of way of looking at Crom is that it provides a more convenient interface than a URL, yet without the centralization that comes from using names in a registry.
Crom helps you go from a name to a URL (via search heuristics), but it’s the URL that ultimately serves as the identifier. So, if you author a package.json with a name like “d3-format”, that gets expanded to a full URL, perhaps with interactive confirmation. (Or not, because it’s trivial to undo and redo.)
Also, unlike a URL to the ZIP file directly, a package URL in Crom supports semantic versioning: it refers to all versions of a project, and thus you can upgrade or specify a desired version range.
Hopefully it will encourage developers beyond js to create usable, composable modules. (LaTeX comes to mind...)
https://github.com/VundleVim/Vundle.vim
It's one of those things that works so well you can just kind of forget about it once you get used to it, but you're not really locked in either.