Soller: Real hardware breakthroughs, and focusing on rustc
Soller: Real hardware breakthroughs, and focusing on rustc
Posted Dec 6, 2019 16:50 UTC (Fri) by nim-nim (subscriber, #34454)In reply to: Soller: Real hardware breakthroughs, and focusing on rustc by farnz
Parent article: Soller: Real hardware breakthroughs, and focusing on rustc
However, I suppose that what makes my distributions friends working on rust most unhappy, is the constant dev churn, because devs do not know or use the default system crate locations, and just push change over change without trying to reuse stabilized crate versions.
Posted Dec 6, 2019 17:01 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (2 responses)
In practice, you'd do this setup once, and not repeat it - unlike an env var, it's then persistent forever. There's no need to version the paths of crates; crates include metadata that identifies their version, and you can rename them to include versioning without ill effect in your system crate pile.
And the dev churn really isn't that bad in Rust - not least because Cargo does semver aware versioning to begin with, so most crates ask for things by semver-aware version.
Posted Dec 6, 2019 20:05 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link] (1 responses)
That’s a dev POW. A dev sets up its environment, it then never changes.
To get distribution synchronization, you need an environment shared by every dev, every packager, and the buildsystem. That means either an hardcoded default location, or a setting in a default system config file, or at least something dirt easy to set, like an environment variable.
Not relying on everyone setting manually the same default in each and every build env.
> There's no need to version the paths of crates;
Unless there will never be two rust apps that need the different versions of the same crate to build, you need to version paths because otherwise the paths will then collide at the share distribution level.
And you can say
> you can rename them to include versioning without ill effect in your system crate pile.
Yes we can do a lot of things at the system level. At some point people tire of working with stuff that need massaging before being used.
> most crates ask for things by semver-aware version
If crates always ask for the latest semver available, because devs have to pull things from the internet (there is no shared system crate store) so why not pull the latest one while you're at it, you *will* get a race to the next version and constant churn.
Posted Dec 6, 2019 20:14 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
Crates do not ask for the latest semver available, because Cargo locks down crate versions on first build of a binary target. So, once I've specified (say) lazy-static = "^1", the first time I do a build with that dependency, Cargo will record the version of lazy-static it found, and use that for subsequent builds; I have to explicitly demand an update from Cargo before it will move onto a new version.
If I'm working in a workspace, then Cargo will resolve deps workspace-wide, and lock me down workspace-wide; this is the recommended way to develop Rust, as it means that you don't bump versions of crates you depend upon, unless you explicitly ask Rust to do that.
And I would note that this is no different to my experiences as a C developer working on the kernel and graphics drivers - when doing that, I used the kernel, libdrm, Mesa3D, intel-gpu-tools and the entire X.org stack from git to avoid duplicating work, and ensure that if I *did* have a fix for a problem, it wouldn't conflict with upstream work. The only difference in Rust is that, right now, there's a lot of churn from Rust being a young language.
Soller: Real hardware breakthroughs, and focusing on rustc
Soller: Real hardware breakthroughs, and focusing on rustc
Soller: Real hardware breakthroughs, and focusing on rustc