> That said, I'll add some Manual Install instructions to the readme so it's clear how to do this on your own

Yeah, that helps a lot :)

I saw this, was like "cool, I want to use this", and then noted that it uses npm. I avoid installing ruby and node apps -- I have nothing against either, just that I currently don't use either language or have a dependency on a major tool written in those; but they pull in a lot of deps which take up space (at least, my experiences have been that many of these tools install way too much -- probably because I don't use either and all the "default libs" aren't on my system). On my previous machine I had lots of issues with this, so as a rule I avoid these things unless absolutely necessary. I know others who are of a similar opinion.

Fortunately I realized that it was just a shell script, and installed it directly :)

> The short reason is that NPM is the most straightforward way to get a script installed as a global binary in a cross-platform manner

Really ? All Unix-like systems (incl OS X) can do this:

    /usr/bin/install myscript.sh /usr/local/bin

PS: Oh, just realized that there is npm uninstall as well, but not /usr/bin/uninstall (though it's just rm -f anyway)

`install` isn't package management, or anything close to that.

Or use FPM (https://github.com/jordansissel/fpm/wiki) and abstract the whole packaging idea. linux and mac packages supported.

I see a lot of projects that's written in other languages on npm, especially bash. Substack even published c code to npm. I think it makes the script more accessible especially for nodejs users. I don't mind publishing it to other package mangers.

Please do not confuse 'more accessible specially for', with 'less accessible and exclusively for' nodejs users.

Last I tried, npm didn't even work on IPv6, even if there's some transition mechanism in place (eg: NAT64).

It's really pretty awful as a distribution mechanism. Why not a simple Makefile?

I had no reasons to use this package, but now I have one to not use it. I only wanted to see what it was because the name suggested something fun.

Why whould someone who can't add $HOME/bin to $PATH be using git?

I realize your question is rhetorical, but there are tons of people. Anyone new to programming, in a CS course that uses git, for example, would be familiar with basic git but many would be unfamiliar with the path (or on Windows).

I concur, but they need not stay unfamiliar with it. The concept is easy: When you type the name of a program and hit enter, I look it up in a list of directories to see the first one that contains a file with that name. That list is $PATH. Any programmer will have to deal with search paths and stuff at some point in their life, and probably very early on, when they'll want to run their own scripts.

I agree that most programmers will run into $PATH at some point, but why force an order on them? Maybe they just want to get started using things like fancy diffs provided through package managers like npm.

git is a content tracker.

People who don't need to edit PATH might still need to track content.

Git is a revision control system.

Nodejs is a programming language.

NPM is a tool to fetch libraries for node programs.

Thus NPM and Git are software development tools.

A software developer or a power user are supposed to know what $PATH or %PATH is.

Wouldn't it be easier for the end user if you used pip/PyPi? Essentially all Linux distros include Python, but there are very few that ship with Node.js installed by default.

I can only speak for myself, but my systems all prohibit installation of packages into the system Python namespace by default.

Yeah, I try to avoid "sudo pip install" for CLI utilities if I can (and discourage its use to others). I put ~/.local/bin on my PATH (nonstandard XDG -like convention) and use "pip install --user" instead.

I've seen too many Python environments hosed by folks who aren't Python experts to keep suggesting that "sudo pip install <CLI tool>" is a thing most users should be doing.

I use ~/.bin/ for what sounds like the same purpose. I'm not sure I'd call that a convention - it's just what made sense to me - but it does ease issues requiring that userspace executables be on my $PATH.

So you need to be root to write to /usr/local/bin/. How does NPM magically solve this? (pip has the `--user` flag to install for just the current user, as tom points out.)

It doesn't solve it, and I don't think I claimed it did - I simply inferred that I don't think installing it into the system (or user) Python is a good idea either.

Ah, I see, I misunderstood your comment. But I think pip gives you better options than NPM, which installs into either /usr/local/(...) or the current directory. The latter sounds like a mess waiting to happen.

And most of distros don't come with pip, so we're back at square one.

Python >= 2.7.9 or >= 3.4 ships with pip installed by default. Those versions are more than a year old now. What are you running, Slackware or something?

I would double check that if I was you. My Debian Jessie machine (from the official Vagrant box) reports Python 2.7.9. No pip.

I've many Debian servers without nodejs _and_ without python.

It requires conscious work as any other dependency, but it's possible (and convenient, if you don't depend on them).

So more than probably, I'll not install npm, to test a bash wrapper to a perl script, that does something that git itself can do without external dependencies.

But obviously, different persons have different concepts of the K.I.S.S. principle.

Being a perl script... why the author didn't use CPAN? it's available in all vanilla installs of Debian, CentOS, Ubuntu, RedHat, etc...

Strange. This is from the official Python docs:

"pip is the preferred installer program. Starting with Python 2.7.9, it is included by default with the Python binary installers."

https://docs.python.org/2.7/installing/

My thought would be that "binary installers" as such are considered distinct from distro-managed packages.

> What are you running, Slackware or something?

CentOS/RHEL?