[pdimitar]

You also can't be more explicit -- and terse -- by running `cargo install ripgrep`.

You said: IF you have to lookup the exact crate name. Well, for 90% of those I use, I don't have to. And it works just fine as your parent commenter said.

You have a preference, cool, but don't try to push it as the better way in an objective sense because it's not. It's just one of the alternatives.

[wokwokwok]

What you’re written it literally false.

You have no idea what that command does. It fetches something off the internet and builds it and installs it.

It is objectively less explicit than having a local folder that you have explicitly fetched, and run a build on.

It is also objectively easier to make a mistake when you type a single command that fetches and installs as one step, than it is to clone, and review then build it.

So, apart from being objectively wrong, I do agree with you; for now, it is easy, convenient and honestly, good.

However, I think you’re being extremely short sighted.

As I said, and as you can see, yourself, from the “command-install” related issues on the cargo issue tracker, the status quo isn’t gong to last. More people will use it. More people will want to distribute binary dependencies and prebuilt binaries.

We are walking blindly into a future where a “cargo install marmelaide” (whoops, was it marmite? Did I spell it right?) installs what you didn’t expect it to, and where people increasingly pressure for more features to be added to cargo to support, the obvious lack of features cargo install currently has (again, read the issue tracker if you doubt me or for some reason think I'm making this up).

I don't support that; but sure, that's just my opinion.

There are other fully featured better designed alternatives. Cargo does not need to be, or should be, a dumpster fire of features in order to be a generic cross platform application distribution tool.

I don't see that as being controversial. /shrug

[CJefferson]

The command you suggest also festches something from the internet and builds it. You could just as easily typo and get someone else's git repository, and again, I'm not going and reading the source code to find out if I have the right program.

I'm not reviewing the source code to ripgrep, and even if I did, I'm definately not review the code of all of it's dependancies, which are getting downloaded when I build it anyway.

Also, it's not objectively easier to make a mistake when you type one command, than when you type three. I would say my error rate goes up as I type more, so I feel it's objectively easier to make a mistake with your method.

Also, why not have cargo install stuff? It already does. If it makes ten thousand's people lives easier, by letting them type one line instead of three, and have to go find the right git repository to clone, then surely that's better?

Also, you still haven't discussed that your method does the (in my opinion) clearly wrong thing of building whatever the current state of the master branch is, rather than a release.

[wokwokwok]

> Also, it's not objectively easier to make a mistake when you type one command, than when you type three.

It is; because you can pause between doing those three commands. Adding a review step objectively lowers the error rate in activities. That's why we do PRs.

> I would say my error rate goes up as I type more, so I feel it's objectively easier to make a mistake with your method.

The word you're looking for is 'subjectively', not 'objectively'.

> Also, you still haven't discussed that your method does the (in my opinion) clearly wrong thing of building whatever the current state of the master branch is, rather than a release.

Use `git clone -b`... or, use a a proper package manager with support for features like parallel binary dependencies and prebuilt binaries.

[dankwizard]

It's wild you're ending all your comments with /shrug - You made a bad take, double downed, and continue to dig.

/shrug