[CAS] Prefix folder names with package name about ied HOT 15 CLOSED

I agree that it's a problem, on the other hand it kind of defeats the point of having content-addressable directory names for dependencies if you put an arbitrary name in front of it.

That being said we could simply ignore the prefix.... So yes, if you someone figures out an elegant way to implement this, I'm very open to it.

from ied.

Per http://nixos.org/nixos/about.html, NixOS appends the package names (rather than prepend, as proposed here). The length of the hash is going to be constant, and you can just ignore everything after that.

from ied.

I like it prepended because it'd make stack traces easier to visually skim through.

  in /home/me/project/node_modules/[email protected]_d3a4db3ac0f..
  in /home/me/project/node_modules/[email protected]_a92bde83a..
  in /home/me/project/node_modules/[email protected]_ba93da28b..

It will also make ls node_modules easier to read—but that's subjective, you can argue the same for the suffixes :)

from ied.

as a side note, @ is valid in pretty much every modern file system, including Windows's.

from ied.

I don't think that the feature is really necessary.

However, I'd like to put these generic directories with packages into a special folder like node_modules/.ied. Then you will get pretty neat node_modules folder

└── node_modules
    ├── .bin
    ├── .ied  
    │   ├── 007704b84df1d82a87334f0c9f938e2cac97257f
   ... ...   // many packages here, probably you don't want to see them all
    │   └── b09d9dfba0b63b9785058b54275729473bd135b0
    ├── browserify -> .ied/8ed522c44cb00acf0234c9b74828e715391f59fc
    ├── express -> .ied/51f1744ec7fffebfd6e2b295ce5e5cb3c9471abd
    ├── grunt -> .ied/39b1b8b7f0ec6ef2be6c77ed350cda1b935a31a0
    ├── gulp -> .ied/3ee1c61aaaf79cd68fe1dfb0233a42f456d9bd61
    ├── lodash -> .ied/8e3ad7e208585af98fd70ba00dcc2592de325e6e
    ├── mocha -> .ied/2bb91c10ac787d29b5a3e9de0c49e81b89aa8f5b
    └── tape -> .ied/54ec118d96f3a42442a3084ebccd3c93eb6db829

That can be a thing that you are actualy want.

from ied.

@just-boris How does this simplify anything? Say you get a stacktrace emailed to you – you literally have no idea what's going on unless you ssh into the server to see what all the hashes match up to. The neat directory is merely aesthetic, no?

@rstacruz The @ symbol seems like a great idea 👍

from ied.

@brianreavis that is probably a valid point, thanks for pointing this.

Scoped packages are installed in the folder prefixed with @, so there is nothing wrong to have a folder like @scope/[email protected]. Also, the hashsum suffix seems here as redundant because it consists from sha(name + '@' + version), so now we just can replace directory name generating logic and it possibly will work

from ied.

Append or prepend both sound fine, I can see pros and cons of both. Is it work considering a shorter hash too, 10 or 12 hex character perhaps? Are there practical disadvantages to a shorter hash (10 hex chars is still over a trillion uniques)?

from ied.

@davej once again, we can get rid of hashes in folder names at all.

I just haven't tried to implement it, but it seems possible.

from ied.

@just-boris: I thought the folder names were CAS, i.e.. generated from content checksum rather than the package + version. I'm on mobile phone so can't look at the codebase now but from the readme:

node_modules as CAS - Packages are always being referenced by their SHA-1 checksums. Therefore a node_modules directory can be considered to be a Content Addressable Storage, meaning that packages are being identified by their contents, not by arbitrary identifiers, such as package names that are not guaranteed to be unique across different registries.

from ied.

@davej, oh, sorry. There were some changes, and that sentence from the Readme is not actual and should be updated.

Now folders names is not actually a shasums of the content. It was a necessary change to support other package sources, like git of arbitrary tarballs. (They don't provide shasum of its content in advance like npm registry does).

So now, it is easy to change it and bring some humanity into folder names and provide more friendy stack traces for users.

from ied.

Cool, well then I guess it makes perfect sense to drop the hash.

from ied.

dropping the hash sounds like a fantastic idea. really excited for the future of ied.

from ied.

just chiming in with some lessons learned in my own implementation.

you can't always expect name@version to be unique if you're also fetching from non-npm registries (eg, installing from tarballs). this is a possible case in a dependency tree like:

- [email protected]
  - [email protected]
  - [email protected]
- [email protected]
  - a patched [email protected] fetched from git or http

in those cases, you can use name@version#hash (where hash is derived from the URL or something) for the non-npm-based modules.

from ied.

Current implementation is fine. Prefixing CAS names with package names kind of defeats the purpose of having CAS names in the first place in my opinion. You can get the package name either from the package.json or from the respective symlink. I don't see an issue here.

from ied.