4 ms·

I want to see an 'algebra' approach to packaging -- strongly-typed packaging modeled as types and operators. Package and import systems present a lot of surpris

I want to see an 'algebra' approach to packaging -- strongly-typed packaging modeled as types and operators. Package and import systems present a lot of surprising behaviors and edge cases in part because they're not well-defined enough to be well-documented. Also, packaging systems need to get better at integrating with VCS versioning. The elm packaging system goes beyond this to automatically bump versions when your api changes https://github.com/elm-lang/elm-package#version-rules https://github.com/elm-lang/elm-package#version-rules, whoa cool. But at minimum, make a note of git/hg id. The 'just use npm' approach is interesting too http://dominictarr.com/post/25516279897/why-you-should-never-write-a-package-manager http://dominictarr.com/post/25516279897/why-you-should-never.... NPM's approach to 'dependencies of dependencies' has a lot of fans. Finally: part of the problem here is that there's no package manager for C. The author dances around this in saying 'C extensions are hard, we should ignore them'. If we had a good C package manager a lot of work linux distros do in supporting C libraries would be simplified and builds of everything would be so much more portable.

gizmo385 11y ago
Am I the only person who doesn't like NPM? I've found it to be somewhat cryptic on errors that I've received and much less intuitive than Brew or apt-get.
derefr 11y ago
> NPM's approach to 'dependencies of dependencies' has a lot of fans. NPM's approach works for Javascript because package A importing libfoo-1.0 and package B importing libfoo-2.3.11 doesn't cause any sort of global namespace collision for "Foo" within the JS runtime; each Foo is just a property of the object returned by require(). This isn't true of most other platforms; you can't e.g. import two versions of a Ruby library into the same Ruby runtime. (You can import two versions of an Erlang module into the same BEAM VM, but the second one will be treated as a code upgrade for the first. Processes that don't do a full-qualified tail-call will stay on the "old" version, though, so both versions can be loaded in parallel. There's still only one global "module table", though.) On the other hand, the "packages get their own scratch namespaces which their dependencies can be exposed into" is true of Unix (or rather, can be made true by clever use of symlinks/chroots/etc.), which is why Nix can do what it does.
- awinter-py 11y ago
  Solid point -- the py import system uses global sys.modules, so npm-style nested deps couldn't happen on a vanilla python. That said, it's not impossible to hack the import command to use a different package tree per module. The main difficulty would be supporting the different ways of storing modules (eggs, filesystem, .so support).
DannoHung 11y ago
You want Nix. Everyone wants Nix. But we're not allowed to have Nix. Because the world sucks and people look at something that has a little bit of necessary complexity and think, "I don't like complexity! I'll build something simpler", and they build it, and it looks cool because it seems simple, but then you use it and it turns out it has implicit complexity.
- zem 11y ago
  there's also the rather more significant issue of nix not running on windows. that pretty much makes it a non-starter for any cross-platform language's package manager.

gizmo385 11y ago

Am I the only person who doesn't like NPM? I've found it to be somewhat cryptic on errors that I've received and much less intuitive than Brew or apt-get.

derefr 11y ago

> NPM's approach to 'dependencies of dependencies' has a lot of fans. NPM's approach works for Javascript because package A importing libfoo-1.0 and package B importing libfoo-2.3.11 doesn't cause any sort of global namespace collision for "Foo" within the JS runtime; each Foo is just a property of the object returned by require(). This isn't true of most other platforms; you can't e.g. import two versions of a Ruby library into the same Ruby runtime. (You can import two versions of an Erlang module into the same BEAM VM, but the second one will be treated as a code upgrade for the first. Processes that don't do a full-qualified tail-call will stay on the "old" version, though, so both versions can be loaded in parallel. There's still only one global "module table", though.) On the other hand, the "packages get their own scratch namespaces which their dependencies can be exposed into" is true of Unix (or rather, can be made true by clever use of symlinks/chroots/etc.), which is why Nix can do what it does.

awinter-py 11y ago
Solid point -- the py import system uses global sys.modules, so npm-style nested deps couldn't happen on a vanilla python. That said, it's not impossible to hack the import command to use a different package tree per module. The main difficulty would be supporting the different ways of storing modules (eggs, filesystem, .so support).

DannoHung 11y ago

You want Nix. Everyone wants Nix. But we're not allowed to have Nix. Because the world sucks and people look at something that has a little bit of necessary complexity and think, "I don't like complexity! I'll build something simpler", and they build it, and it looks cool because it seems simple, but then you use it and it turns out it has implicit complexity.

zem 11y ago
there's also the rather more significant issue of nix not running on windows. that pretty much makes it a non-starter for any cross-platform language's package manager.