Deebster, 11 months ago

People who see my code start feeling ill and start shifting their eyes nervously.

To be honest, I had this reaction just reading your description. But, if it's a only personal project there's no harm, as long as you're not selling it as a new best practice!

anlumo, 11 months ago

I once had a project where I added a crate and a completely different part of the application that didn't use that crate broke.

Turns out that I didn't include the patch version in a dependency and that new dependency required an earlier patch version that had a critical bug in it.

Your solution is like this, but even more extreme by also allowing a dependency to get your code to link to an old major version, breaking everything.

So, your solution only works if you don't plan to ever add a new dependency.

njaard, 11 months ago

In practice, I have about 10% of my dependencies not have the latest version, according to cargo-outdated, once I complete a cargo update.

PrincipleOfCharity, 11 months ago

For personal projects this is fine, but I’m curious why you feel the need to have every crate be the newest? Once you have it compiling, why upgrade dependencies at all unless you have to? Compiling a new binary is way more work than just running the one that is already compiled. You talk about minimizing build times with this method, but it isn’t clear why recompiling at all with newer dependencies is beneficial.

Theoretically, every update to a crate is better than the last, but sometimes it’s just adding non-breaking features that you weren’t using anyway. You could just check crate updates every once in a while looking for performance gains or features you would like to make use of.

anlumo, 11 months ago

Could also be performance benefits. You could research into updates of every dependency (and some crates don't publish changelogs, so you have to dive through commit messages), but who has the time for that?

admin, 11 months ago

I can somewhat relate. I mostly do something like this (instead of the exact dependency version):

chrono = {version = "0", features = ["serde"]}
clap = {version = "4", features = ["derive"]}
anyhow = "1"

I do, however, typically write application code instead of library, so it's probably less critical for me. Occasionally do run into dependency hell here and there, but nothing too bad so far!

refefer, 11 months ago

I can certainly see the trade-offs. I typically write high performance optimizers, so my dependency list is fairly compact; the big risk I see in general, without knowing anything of you application, is bug fixes or quality of life improvements. Those that manifest as full version bumps are fairly insidious with '*', and can make porting to the future a potential nightmare.

All that said, there's something nice about using a fixed version of common crates to develop against. One of the big advantages of languages like Python and Go is that robust stdlib which makes many tasks trivial to program assuming a wide enough coverage of libraries.