[wokwokwok]

> cargo install marmite

I'm not the only one (1) that believes this is wrong direction for cargo, and is abusing it's intent and purpose.

If you want to distribute an application, there are lots of ways to do that. If it's a developer tools, for developers, `cargo install` might be suitable, sure... but I think there's a fair argument to be made that if you want a tool:

    git clone foo
    cd foo
    cargo install --path .

Is an explicit, safe and less error prone way of doing it.

...and one that doesn't walk us down the road of (see the linked thread) the obvious desire people are going to have sooner or later to cache binary builds instead of building locally, and turn `cargo install` into some kind of binary application distribution application or app store.

If you don't believe me, read that thread, and the linked thread.

[1] - https://github.com/rust-lang/cargo/issues/13994#issuecomment...

[CJefferson]

I don't understand why your suggested version is more explicit, safer, or less error prone. You'll have to justify that to me!

'cargo install ripgrep' has worked on every machine I've run it on. It's also easy for me to send to other people I work with.

Your suggestion requires me go and find the repository. If I just clone the repository it's going to get the current master branch, not the most recent release (which sounds less safe and more error prone to me!)

[wokwokwok]

Crates.io is a flat namespace.

If you have to lookup the exact crate name (and you do, because otherwise you’re installing who-knows-what) what difference does it make?

It’s just a lazy tool for lazy installs that only works when there are a) not that many people using it (easy memorable names that aren’t easy to mess up still exist), and b) no bad actors squatting on typo names.

You can’t be more explicit than “build and install this folder I have”.

/shrug

[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

[voxl]

The own thread you linked is clear as day: cargo install is good and should continue to be used as way to install binaries _by building them_

Your objection then or thinking invoking cargo install at all is abuse is highly questionable. In fact, I would wager that vast, vast majority of the Rust community vehemently disagrees with you.

In the own thread you linked there is community support for binary installs with cargo bininstall

[wokwokwok]

bininstall is a third party project.

There’s nothing wrong with building an app store in rust; I’m just saying that it shouldn’t be part of cargo.

> brew install cargo-binstall

…and it is not. It’s a great project, and if you want to use it, you can.

Using rust does not opt you into using it, just like it doesn’t opt you into using brew.

[rochacbruno]

My goal is to build binaries and have it distributed to the most used package indexes out there, I didn't get there yet.

[pepa65]

I just tried `cargo binstall marmite`, but it feels (in this case?) that it was the same as doing `cargo install`. Anyway, if you have cargo (ergo, the whole rust toolchain), you might as well explicitly download the git repo, as things need to be downloaded when you do a plain `cargo install` as well. A rust-sanctioned way to get just binary builds that do not require the whole rust toolchain installed would be best. There is a single-binary `cargo-binstall` but that only works when there is made provision by the crate to make a binary available.

[pepa65]

Confirmed, cargo-binstall is not configured for Marmite, so cargo will fall back to install, and the single-binary cargo-binstall will try its heuristics which do not detect ubuntu-latest-binary.zip or macos-latest-binary.zip.

[rochacbruno]

Good catch, I will try to learn how cargo-binstall works and provide the proper binary files.

There is an open issue to improve the Github Actions CI related to build and release.

[lynndotpy]

I like cargo because it's an easy way to install programs. Pip and npm are used like apt and yum too.

This is a feature to me, not problem, and it has been this way for many years.