3 ms·

Among all the software I use, Homebrew must be the one giving me the least trouble. I have 100 installed packages and I don't remember the last time anything di

Among all the software I use, Homebrew must be the one giving me the least trouble. I have 100 installed packages and I don't remember the last time anything didn't work. Plus, for anything I care about, updates seem to always take less than a day, usually it's almost instantaneous. In comparison with MacPorts before, it's like night and day. npm/pip/mix/bundler all seem to periodically conspire to waste a few hours of my time (even though I can do that quite well on my own). NPM being the worst of the bunch. By a lot. About this much: `tree node_modules`

philplckthun 10y ago
So npm is bad in your opinion, because it correctly handles different dependencies on packages with varying versions, screwing up? Or is the problem the vast js ecosystem? I don't think that "tree X" can be a good argument against using any kind of package manager.
- kminehart 10y ago
  It's just popular to hate JavaScript and npm right now. It's not perfect, but it's not bad either.
  - philplckthun 10y ago
    This whole "JS and it's ecosystem is the worst"-meme is just awful. Same goes for the PHP counterpart. I think it's fine to search for better solutions for our backends, but there is no denying that 1) our browsers rely on JS and will do so for the close future, and 2) that there is an ecosystem for every programming language that can use it efficiently and proficiently.
- azdavis 10y ago
  Yeah, I'm not seeing how "tree node_modules" is an argument against npm per se. Maybe one could argue npm, inc promotes the small-modules approach, but I don't think that's relevant to whether npm itself is a good package manager. No matter whether you think small modules are good or bad, I personally have experienced npm to at least manage them well. Admittedly, however, I've never actually worked on projects of any great size.
lloeki 10y ago
The dire status of MacPorts and Fink was the impetus behind Arch OS X back then, but Homebrew's success and ease of use combined with the build-from-source design (it was a real plus not having to host binary packages at the time) preempted that effort. Some design choices still rub me the wrong way to this day though (quibbles to some, but for a couple use cases it can matter), that's why I'm trying hard to bring back Arch OS X to life. Anyway, congrats to the Homebrew team! They truly deserve it.
- wyuenho 10y ago
  MacPorts started as a build-from-source package manager. The introduction of prebuilt binary packages is a recent addition. It was added only because some packages took a really long time to build. Fink is full of old packages, but MacPorts ports are pretty up to date. There are still lots of devs maintaining MacPorts these days. So I don't know what dire status you were talking about.
  - ssalazar 10y ago
    > Fink is full of old packages, but MacPorts ports are pretty up to date. There are still lots of devs maintaining MacPorts these days. So I don't know what dire status you were talking about. At the time Homebrew rose in popularity it was super easy to add packages to and update existing packages. MacPorts had a reputation, at least, for being inflexible and difficult for casual maintainers. Some not-completely-esoteric packages would not be updated from upstream sources for years. In my case there was (still is?) the particularly strange case of GNU Octave, in which the development version (octave-devel) had completely superceded the regular package (octave), and this was not really well documented. To get anything done at all with Octave you had to use octave-devel, while octave was essentially a vestigial limb floating around for no reason.
guitarbill 10y ago
pip is atrocious/dangerous on any system without virtualenv. I've managed to sort this by using virtualenvs where I can and homebrew Python + packages when I can't (numpy, etc.). Two things really help: pipsi (https://github.com/mitsuhiko/pipsi https://github.com/mitsuhiko/pipsi), which installs tools inside their own virtualenv and PIP_REQUIRE_VIRTUALENV, which stops pip from working outside a virtualenv.
- xapata 10y ago
  You could try conda. It's basically a pip and virtualenv that works on non-Python dependencies.
  - guitarbill 10y ago
    That's actually awesome, thanks!

philplckthun 10y ago

So npm is bad in your opinion, because it correctly handles different dependencies on packages with varying versions, screwing up? Or is the problem the vast js ecosystem? I don't think that "tree X" can be a good argument against using any kind of package manager.

kminehart 10y ago
It's just popular to hate JavaScript and npm right now. It's not perfect, but it's not bad either.
- philplckthun 10y ago
  This whole "JS and it's ecosystem is the worst"-meme is just awful. Same goes for the PHP counterpart. I think it's fine to search for better solutions for our backends, but there is no denying that 1) our browsers rely on JS and will do so for the close future, and 2) that there is an ecosystem for every programming language that can use it efficiently and proficiently.
azdavis 10y ago
Yeah, I'm not seeing how "tree node_modules" is an argument against npm per se. Maybe one could argue npm, inc promotes the small-modules approach, but I don't think that's relevant to whether npm itself is a good package manager. No matter whether you think small modules are good or bad, I personally have experienced npm to at least manage them well. Admittedly, however, I've never actually worked on projects of any great size.

lloeki 10y ago

The dire status of MacPorts and Fink was the impetus behind Arch OS X back then, but Homebrew's success and ease of use combined with the build-from-source design (it was a real plus not having to host binary packages at the time) preempted that effort. Some design choices still rub me the wrong way to this day though (quibbles to some, but for a couple use cases it can matter), that's why I'm trying hard to bring back Arch OS X to life. Anyway, congrats to the Homebrew team! They truly deserve it.

wyuenho 10y ago
MacPorts started as a build-from-source package manager. The introduction of prebuilt binary packages is a recent addition. It was added only because some packages took a really long time to build. Fink is full of old packages, but MacPorts ports are pretty up to date. There are still lots of devs maintaining MacPorts these days. So I don't know what dire status you were talking about.
- ssalazar 10y ago
  > Fink is full of old packages, but MacPorts ports are pretty up to date. There are still lots of devs maintaining MacPorts these days. So I don't know what dire status you were talking about. At the time Homebrew rose in popularity it was super easy to add packages to and update existing packages. MacPorts had a reputation, at least, for being inflexible and difficult for casual maintainers. Some not-completely-esoteric packages would not be updated from upstream sources for years. In my case there was (still is?) the particularly strange case of GNU Octave, in which the development version (octave-devel) had completely superceded the regular package (octave), and this was not really well documented. To get anything done at all with Octave you had to use octave-devel, while octave was essentially a vestigial limb floating around for no reason.

guitarbill 10y ago

pip is atrocious/dangerous on any system without virtualenv. I've managed to sort this by using virtualenvs where I can and homebrew Python + packages when I can't (numpy, etc.). Two things really help: pipsi (https://github.com/mitsuhiko/pipsi https://github.com/mitsuhiko/pipsi), which installs tools inside their own virtualenv and PIP_REQUIRE_VIRTUALENV, which stops pip from working outside a virtualenv.

xapata 10y ago
You could try conda. It's basically a pip and virtualenv that works on non-Python dependencies.
- guitarbill 10y ago
  That's actually awesome, thanks!