Follow up of #112
Personally, I dislike Homebrew, and would rather not support it from a philosophical standpoint, nor from a maintenance standpoint. In addition, it seems like the only advantage would be easy updates - and if that's something a lot of people want (see #112, #400, #275, #127, for examples), then that's a feature we should add, not delegate to a kitchen sink package management system.
For example, we could add an nvm update function that updates itself, although that might be tricky given that it can be installed from git or from the script.
@ljharb Well, it's easy to dismiss a package manager for managing your own project that you: a) probably test often locally on pre-releases, b) need to tweak manually often. Package manager wouldn't buy you anything and you spend your energy on this tool anyway.
But when someone needs gazillion tools to manage multiple things, e.g. nvm, haskell-platform, redis, etc. etc. then managing every single one of them individually would be a huge PITA, it would be simply unmaintainable. That's what Homebrew is for.
Amen: "But when someone needs gazillion tools to manage multiple things, e.g. nvm, haskell-platform, redis, etc. etc. then managing every single one of them individually would be a huge PITA, it would be simply unmaintainable. That's what Homebrew is for."
This is exactly my sentiment. I think if you simply built a resilient update mechanism and then allowed homebrew to do its thing via a simple update call, that's a win-win. brew update + brew upgrade are handy to not forget about things like nvm.
I don't use homebrew either and can't justify the time to learn the proper recipe syntax to write one.
I do understand how it's useful to a lot of people. What's wrong with just installing nvm from git and doing a git pull to update the local copy? Can the recipe assume a git checkout?
@creationix We're now using release tags, since relying on the latest master to be stable isn't a great idea. For a git pull to work, we'd have to use a latest tag that moved - which would make seamless clientside git updating trickier.
you could just have a stable branch, the downside there is you'd have to
remember to update it every time there is a new tag.
For the record, that's current Homebrew formula for nvm: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/nvm.rb
Just an example of the ridiculousness there: Node installs will be lost upon upgrading nvm - wtf? that's not a flaw in nvm itself, that's a flaw in the homebrew formula.
Only thing that has to be done is add a line to your profile to prevent that. Nothing different from the regular install, that needs a line in your profile as well.
right, but that should be the default behavior (to keep node installs). It gives this package a bad name to have such a crappy experience elsewhere.
On Fri, Jul 18, 2014 at 9:51 AM, Jordan Harband [email protected]
wrote:
Node installs will be lost upon upgrading nvm
AFAIK that's no longer true.
That said, I dumped Homebrew's nvm; Node is a thing I use daily so I want
to have nvm version as official as possible. But I sympathize with other
users.
I had problems with zsh's nvm plugin since Homebrew's formula installs nvm
to /usr/local/opt/nvm/NVM_VERSION but at least Node versions are put in
~/.nvm (i.e. NVM_DIR is set correctly).
+1 for an official homebrew recipe, agree with @ylluminate - I use a ton of different software packages, I want to centralize updates (brew upgrade) whenever possible.
right, but that should be the default behavior (to keep node installs). It gives this package a bad name to have such a crappy experience elsewhere.
The thing is, brew installs software to $(brew --prefix)/Cellar/{package}/{version}. It links the latest to a path that ends up in your search path.
Where that goes wrong, at least with nvm is that nvm by default assumes you want your node versions in the same directory where nvm is installed.
Depends on how you look at it who is wrong. I personally do not think there is a single correct answer and pretending there is one seems a bit irresponsible.
Either way, for those that want to have a good experience, setting NVM_DIR to something sane is fine. I personally have it set as depicted below:
export NVM_DIR=$XDG_DATA_HOME/node
Life is good.
The maintainers of a piece of software are always right, never the package manager that chooses to distribute it unofficially.
Thanks for the helpful example for those who still choose to use brew :-)
The maintainers of a piece of software are always right, never the package manager that chooses to distribute it unofficially.
:+1: - agreed.
Thanks for the helpful example for those who still choose to use brew :-)
Indeed!
Just a slight defense of a "package manager" in general...
I just read this thread and said "Ok, I'll just install for source, they made a valid point".
All finished... says to restart my terminal? That's weird, why can't I just source it... ok restart.
nvm command not found
Hmm..
Try install again:
=> Source string already in /Users/framerate/.bashrc
=> Close and reopen your terminal to start using nvm
Wait... .bashrc? I'm using zsh! Readme says:
The script clones the nvm repository to ~/.nvm and adds the source line to your profile (~/.bash_profile, ~/.zshrc or ~/.profile).
... but that didn't seem to be the case here.
I then copied the line(s) to my .zshrc and everything is fine.
This is a prime example of WHY I use the package manager. I need a tool, and thanks to someone's hard work on making the formula, I can just do:
brew install nvm
And _usually_ everything goes well!
@ljharb you said re: homebrew:
It gives this package a bad name to have such a crappy experience elsewhere.
But I would argue that my experience just now wasn't any better....
Either way, thanks for making such a great important piece of software! I just beg you to remember the good things a package manager can bring to the table for distributing your software, letting you focus more on making it awesome and getting into as many people's hands as possible!
@framerate thanks for your input! The messaging certainly says "bash", and the documentation could stand to be updated, but the install script should install into zshrc for you. If not, that's a bug we need to fix.
Rather than someone doing "hard work" to make a formula, selfishly confining the benefits of that work to homebrew users, why can't that work be done in pull requests to make nvm itself better for everyone?
I wouldn't say it's selfish at all! Homebrew (and macports and other package managers I'm sure) have tons of users.
I think it's our job to make sure our tech is great but ALSO to make sure it gets to as many people as possible.
Isn't this why we have NPM? I mean, I could just clone github repositories directly... 'npm i express' is just easier.
Or why does NVM exist in the first place? Can't I just install multiple versions and and create symlinks myself?
I'm sure you get my side here. These are all tools that people use to make their workflow work for them. You have no requirement to support all the tools, I just sensed quite a bit of hostility towards homebrew in this thread and wanted to speak up in defense.
Homebrew, npm, nvm, apt-get .... they're all just tools to make our days less stressful. And I'm glad ALL of them exist :)
(full disclosure I avoided homebrew too for about 2 years... I finally decided to drink the koolaid last year and it has made managing node/mongo/redis on my dev machine A LOT easier for me)
and adds the source line to your profile (~/.bash_profile, ~/.zshrc or ~/.profile)
I personally never liked this practice. It's brittle and a bit short sighted.
full disclosure I avoided homebrew too for about 2 years
@framerate:
I did the same initially; however, all of my troubles went away once I stopped allowing homebrew to usurp /usr/local. I install into ~/.homebrew and life has been good ever since.
Rather than someone doing "hard work" to make a formula
I originally created it for just myself. It's a simple .rb file. It doesn't have to be in any special location. Once I realized how much better of an experience it was, I decided to share it by opening a pull request. Not a huge deal. Since then, other people have helped make it better.
selfishly confining the benefits of that work to homebrew users, why can't that work be done in pull requests to make nvm itself better for everyone?
I think homebrew is less about the individual formula and more about the conventions that you can count on. I dare say, you aren't going to get that type of guarantee out of a single pull request or even a handful unless you want to turn nvm into a package manager. Obviously that would be silly.
@wilmoore awesome. I'm going to move nvm into my homebrew flow :)
Thanks for that work! (@ljharb too, nvm is great!)
Please note that any issues with brew-installed nvm are not supported, so when reporting any problems, please brew uninstall and install the proper way first. There's been too many brew-related quirks for my to want to support it.
Thanks for that work!
My pleasure. It's nice to be able to share something with others that worked for me :smile:
when reporting any problems, please brew uninstall and install the proper way first.
@ljharb
This should probably be in the readme.
@wilmoore The README tells people how to install it - if they're installing nvm via brew, they're not reading, or disregarding the README anyways, so I doubt that'd be helpful.
@ljharb
If they are coming to github to submit an issue, I'd suspect that some people may have a peek at the README. Even if they don't, at least you have a single place where you can point them. I don't know, it's just a suggestion, so either way man.
@ljharb I know, I've had the same conversation with the npm guys as well. Abstractions aren't supported by you guys, nor should they be!
As I said originally, your job is to make awesome code and to get the software into as many hands as possible... but not to fix things when those hands mess things up :)
@wilmoore Thanks, I don't mean to be brusque or hostile, and I do appreciate you being generous enough to share something that worked for you with the rest of the internet. The reality though is that unofficial distribution channels for software, like homebrew, make life much harder for maintainers since it either forces them to support that channel, or forces them to require their users to not use it when triaging bugs. My irritation with the entire concept of an unofficial package manager shouldn't extend to you, and I apologize if that's been the case.
I'd be happy to review a PR to add an unobtrusive note to the README, if only to clue people in when they have problems. Thanks for the suggestion!
Just my 2垄: linuxbrew is making my life _so_ much easier as a sysadmin now that I'm using it on a few servers. One thing interesting that I did was to install it under ~/.linuxbrew for an admin user and then created a symlink from it over to /opt/linuxbrew and then modified my env setups for bash and zsh users system wide. Really making things nice for CentOS / cPanel servers + Passenger to run Ruby and NodeJS apps, etc.
nvm via 'brew has been great now for the last few months!
and I do appreciate you being generous enough to share something that worked for you with the rest of the internet
@ljharb Definitely. It's really no problem though. Just happy to share something that works :smiley:
@ljharb: :+1: to officially supporting Homebrew. While you personally may not use it, many of us do. These days, jumping from project to project requires the use of many different tools. It's much easier for me to reach for brew install nvm (which works with almost every other project), than to try to manage installation of every different possible tool that I use. Homebrew may not be the "official" package manager for OS X, but it is definitely the most popular and it's unlikely to go anywhere anytime soon. Just my 2垄.
@ljharb
Node themselves tells people using OSX to install via Homebrew.
Considering the amount of effort spent closing bugs and such, it would make sense to revisit the idea of having an official Homebrew formula.
@SpencerCarstens that's npm, not node.
The effort of closing these bugs is infinitely less than supporting homebrew in my experience.
The effort of closing these bugs is infinitely less than supporting homebrew in my experience.
Makes sense.
What about adding 'nvm update' at least then?
See #400.
@franklinyu every package manager. however, homebrew is frequently broken, while AUR's maintainer has been responsive to my comments. I've never heard of Copr.
Regardless, the only supported installation mechanism for nvm is the curl script in the readme.
I see NVM as a Simple bash script to manage multiple active node.js versions.
Similary I see Homebrew as The missing package manager for macOS (or Linux).
So both are written to help manage installation of other software on one's computer. If I am correct in my findings?
How are they so different that one is disliked and the other is not?
I like coke and not pepsi - that they鈥檙e both soda in no way means anyone will necessarily like either or both of them - and they鈥檙e pretty similar, all things considered.
homebrew and nvm are different projects with different scopes and different userbases and different priorities. If you want to use either or both or neither, more power to you!
However, as stated above - officially supporting a homebrew formula (especially one with a non-broken user experience) is a much larger burden on me, so i opt not to do it.
Please follow #400 for nvm eventually having the ability to update itself in-place; otherwise, i think this issue has been more than sufficiently answered - and since my position here is unlikely to change, I鈥檓 going to close this issue.
Most helpful comment
@ljharb
Node themselves tells people using OSX to install via Homebrew.
Considering the amount of effort spent closing bugs and such, it would make sense to revisit the idea of having an official Homebrew formula.