github.com
"I'm a big user of other SSGs but it is frequently frustrating that it takes so much setup to get started. Just having a directory of markdown files and running a single command sounds really useful. — marmite user."
I see other posts on the page showing `built with Python`, `Python based`, why `written in Rust` was not allowed? just curious.
Ai-folio or academic pages is basically my use case or target, but I want something with zero javascript, which tends to be a bit hard in todays age.
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 .
...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...
'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!)
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
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.
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
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.
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.
/shrug
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
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.
There is an open issue to improve the Github Actions CI related to build and release.
This is a feature to me, not problem, and it has been this way for many years.
Need to think about back references.
In any case if the implementation is simple I would take a PR.
> Marmite is a sticky, dark brown paste with a distinctive, salty, powerful flavour and heady aroma. This distinctive taste is represented in the marketing slogan: "Love it or hate it." Such is its prominence in British popular culture that Marmite is often used as a metaphor for something that is an acquired taste or polarises opinion.
Definitely a faux-ami.
Never thought about how the name would trigger people haha, I love Marmite BTW.
Only a few years more of my life lost to check all of the code of Linux and ensure I know what is running. I'm not bitter about and looking for better solutions to that at all.
FTFY
When I see a CLI tool written in Rust or Go, it usually just works out of the box without having to mess around with godawful pip environments or conda.
"Written in Rust" carries with it significant promises that only Go also has. (Go has a lot of the same promises, for having good tooling and the same mostly-statically-compiled philosophy.)
"Written in Rust" tells me a project is easy to install and easy to hack on. I am far less interested in using non-Rust projects, and I am definitely disinterested in making code contributions to non-Rust projects.
Case in point: It took me much longer to write this comment than it took to install and use marmite.
Yeah this loop will go on with this comment, it seems.
Not fair.. other posts have `written in Python` on it.
Why was that?
*The US federal version of dilution law came into effect in the 1990s.