3 ms·
that's only true if you believe dependency resolution is free.
by PH95VuimJjqBqy 3y ago
that's only true if you believe dependency resolution is free.
- alpaca128 3y agoI have never witnessed cargo being delayed from that by a noteworthy amount of time. I just tried it, on my PC it takes cargo 0.3 seconds to start compiling the first of 309 dependencies in a clean Bevy repo. The entire compilation takes 31 seconds, and that's the best case with lots of multithreading and all packages already downloaded. That's close enough to "free" for me.
- PH95VuimJjqBqy 3y agodoesn't really matter. You said "nothing to do with" and I said "is not free". 1/3 of a second for a build that has already cached all dependencies means I was correct that it's not free and you were being dismissive when you said it had nothing to do with build times. If you want to argue that it's a minimal amount of time then argue that instead of what you've been arguing.
- alpaca128 3y agoI was of course talking about usage in the real world, which is the thing that matters in the end. Harping on the precise meaning of words like that is pointless.
- PH95VuimJjqBqy 3y agothe real world, where nothing means something.
- steveklabnik 3y agoCargo does not do dependency resolution on every build.
- PH95VuimJjqBqy 3y agohow does a dependency management system ensure the dependencies are there without doing dependency resolution?
- steveklabnik 3y agoBy separating the two. If there’s no Cargo.lock, resolution needs to be done, and the result is written out to the lock file. If the lock file is there, then you don’t need to re-run resolution, you just read out the result from the file. The latency you’re arguing over is probably more to do with rustup selecting the right cargo and exec-ing that than dependency resolution. It’s heavier weight than it should be due to history reasons.
- PH95VuimJjqBqy 3y agodealing with the Cargo.lock is a part of the dependency resolution.