4 ms·

It's been a while (almost 2 years) and I don't use ruby much any more, so my memory is a little hazy and for all I know the issues have been fixed. My main com

by defen 13y ago

It's been a while (almost 2 years) and I don't use ruby much any more, so my memory is a little hazy and for all I know the issues have been fixed. My main complaints were that too much magic made it difficult to tell what was being loaded from where; and that it was a ton of work to get proper automated deployments set up (with puppet...in a way that didn't make assumptions about the target machine - RVM was also a huge culprit here). Also, at times it was painfully slow. To be fair I'm not super familiar with the internals - it's totally possible that it's all ruby's fault and any ruby package manager would have the same issues. For every day development bundler was mostly great - it was just painful to get proper deployments working. I much prefer how npm handles things.

steveklabnik 13y ago
Things have changed quite a bit in the last two years. Especially around speed. So things are a lot better now in Bundler land, and should be better with Cargo, too. Cool. > I much prefer how npm handles things. Can you elaborate on how npm handles things in a better way?
- TheHydroImpulse 13y ago
  For one, I love local by default. Having a package manager that deals with a global context makes things considerably more complex. Having everything local allows you to isolate one crate's (if we're speaking in Rust terms) dependencies to another crates' dependencies. NPM also has the ability to have isolated dependencies from each other dependency. For example, module A can pin module B to version 2, whereas module C can pin module B to version 3. So you have independent copies. Now, that worked for a dynamic language where you don't have to deal with static/dynamic linking. Would it be appropriate to statically link two modules that are the same, but at different versions? Maybe not. That would lead to massive binary sizes.
  - steveklabnik 13y ago
    Thank you. > I love local by default. Roger. It's hard to articulate my own thoughts about this, but I feel like Bundler enables the best of both worlds here.[1] That said, it's obviously a preference. > NPM also has the ability to have isolated dependencies from each other dependency. Ahh yes, I've heard about this. In Ruby, it's not really feasible due to the language, and I'm a bit skeptical that it doesn't lead to super extra complexity, but then again, I haven't used it myself... Totally agree regarding static/dynamic linking. Though isn't it the same thing with NPM: you still have two copies of the library. 1: http://words.steveklabnik.com/how-to-not-rely-on-rubygemsorg-for-deployment http://words.steveklabnik.com/how-to-not-rely-on-rubygemsorg...
    - jdlshore 13y ago
      > I'm a bit skeptical that [isolated dependencies] doesn't lead to super extra complexity... It's braindead simple. It's an emergent property of the way node loads modules, which is also pretty darn simple. When you give Node a package to require, if it doesn't refer to a relative or absolute path, it walks up the directory structure looking for `node_modules`. When it finds one, it looks inside for the module you asked for. If it doesn't find it, it keeps walking up the directory tree. So you can have multiple module repositories in a directory tree. A given file will always find the one that's "closest." Npm takes advantage of this by installing every module's dependencies in a `node_modules` directory in the root directory of that module. Subdependencies' dependencies go in their node_modules directory. Voila! Isolated dependencies, braindead simple, albeit with a crazy deep directory structure. (node_modules/foo/node_modules/bar/node_modules/baz...) Node/npm has the best dependency handling I've yet seen, and I think it's because it doesn't try to outsmart me or go for anachronistic disk space optimizations.
      - mercurial 13y ago
        I'm not sure what's anachronistic about efficient use of disk space, but in any case that's nothing that can't be solved via hardlink deduplication.
        13y ago
  - rat87 13y ago
    > NPM also has the ability to have isolated dependencies from each other dependency. For example, module A can pin module B to version 2, whereas module C can pin module B to version 3. So you have independent copies. That seems like a bad idea even in a dynamic language, perhaps especially in a dynamic language. What if you return a type from module A that is defined in module BV2 to module C suddenly it can't find the method(or the method does something different then expected). At least in a static language you could prevent this to some extent. It seems like it would be better to have version ranges and fetch the newest released version or fail if no version is acceptable with interactive/cmdline overrides.
- defen 13y ago
  Fundamentally, I think it boils down to the fact that node's module loader is dumb, and npm doesn't try to be a smart module loader on top of that - it just installs dependencies to where node's dumb loader will be able to find them. And, because of CommonJS, it's easy to tell it exactly where it's allowed to look. One way this manifests itself in a nice way is with local installs - let's say you have a package that depends on modules A, B, and C. Each of those modules has its own dependencies. The default behavior when you install the package is that A, B, and C have copies of all their dependencies (so if all 3 depend on D, you get 3 copies of D), and so forth all the way down. This does waste disk space, but for the most part node modules are small and disk space is cheap. The advantage is that you don't have to worry about conflicting dependencies, or subtle changes breaking things in hard-to-find ways. Like a sibling commenter said, I have no idea if this model will transfer well to Rust.
TheHydroImpulse 13y ago
That's what made it intolerable when I started getting into Ruby years ago. Perhaps this can also be attributed to Ruby being slow, but it was (and still is) too slow to install anything or run commands. This isn't bundler's fault, though, as gem and many ruby CLIs also run super slowly.

by defen 13y ago

steveklabnik 13y ago

Things have changed quite a bit in the last two years. Especially around speed. So things are a lot better now in Bundler land, and should be better with Cargo, too. Cool. > I much prefer how npm handles things. Can you elaborate on how npm handles things in a better way?

TheHydroImpulse 13y ago
For one, I love local by default. Having a package manager that deals with a global context makes things considerably more complex. Having everything local allows you to isolate one crate's (if we're speaking in Rust terms) dependencies to another crates' dependencies. NPM also has the ability to have isolated dependencies from each other dependency. For example, module A can pin module B to version 2, whereas module C can pin module B to version 3. So you have independent copies. Now, that worked for a dynamic language where you don't have to deal with static/dynamic linking. Would it be appropriate to statically link two modules that are the same, but at different versions? Maybe not. That would lead to massive binary sizes.
- steveklabnik 13y ago
  Thank you. > I love local by default. Roger. It's hard to articulate my own thoughts about this, but I feel like Bundler enables the best of both worlds here.[1] That said, it's obviously a preference. > NPM also has the ability to have isolated dependencies from each other dependency. Ahh yes, I've heard about this. In Ruby, it's not really feasible due to the language, and I'm a bit skeptical that it doesn't lead to super extra complexity, but then again, I haven't used it myself... Totally agree regarding static/dynamic linking. Though isn't it the same thing with NPM: you still have two copies of the library. 1: http://words.steveklabnik.com/how-to-not-rely-on-rubygemsorg-for-deployment http://words.steveklabnik.com/how-to-not-rely-on-rubygemsorg...
  - jdlshore 13y ago
    > I'm a bit skeptical that [isolated dependencies] doesn't lead to super extra complexity... It's braindead simple. It's an emergent property of the way node loads modules, which is also pretty darn simple. When you give Node a package to require, if it doesn't refer to a relative or absolute path, it walks up the directory structure looking for `node_modules`. When it finds one, it looks inside for the module you asked for. If it doesn't find it, it keeps walking up the directory tree. So you can have multiple module repositories in a directory tree. A given file will always find the one that's "closest." Npm takes advantage of this by installing every module's dependencies in a `node_modules` directory in the root directory of that module. Subdependencies' dependencies go in their node_modules directory. Voila! Isolated dependencies, braindead simple, albeit with a crazy deep directory structure. (node_modules/foo/node_modules/bar/node_modules/baz...) Node/npm has the best dependency handling I've yet seen, and I think it's because it doesn't try to outsmart me or go for anachronistic disk space optimizations.
    - mercurial 13y ago
      I'm not sure what's anachronistic about efficient use of disk space, but in any case that's nothing that can't be solved via hardlink deduplication.
      - 13y ago
- rat87 13y ago
  > NPM also has the ability to have isolated dependencies from each other dependency. For example, module A can pin module B to version 2, whereas module C can pin module B to version 3. So you have independent copies. That seems like a bad idea even in a dynamic language, perhaps especially in a dynamic language. What if you return a type from module A that is defined in module BV2 to module C suddenly it can't find the method(or the method does something different then expected). At least in a static language you could prevent this to some extent. It seems like it would be better to have version ranges and fetch the newest released version or fail if no version is acceptable with interactive/cmdline overrides.
defen 13y ago
Fundamentally, I think it boils down to the fact that node's module loader is dumb, and npm doesn't try to be a smart module loader on top of that - it just installs dependencies to where node's dumb loader will be able to find them. And, because of CommonJS, it's easy to tell it exactly where it's allowed to look. One way this manifests itself in a nice way is with local installs - let's say you have a package that depends on modules A, B, and C. Each of those modules has its own dependencies. The default behavior when you install the package is that A, B, and C have copies of all their dependencies (so if all 3 depend on D, you get 3 copies of D), and so forth all the way down. This does waste disk space, but for the most part node modules are small and disk space is cheap. The advantage is that you don't have to worry about conflicting dependencies, or subtle changes breaking things in hard-to-find ways. Like a sibling commenter said, I have no idea if this model will transfer well to Rust.

TheHydroImpulse 13y ago

That's what made it intolerable when I started getting into Ruby years ago. Perhaps this can also be attributed to Ruby being slow, but it was (and still is) too slow to install anything or run commands. This isn't bundler's fault, though, as gem and many ruby CLIs also run super slowly.