Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reducing crate_universe lockfile size? #775

Open
dae opened this issue Jun 21, 2021 · 3 comments
Open

Reducing crate_universe lockfile size? #775

dae opened this issue Jun 21, 2021 · 3 comments

Comments

@dae
Copy link
Contributor

dae commented Jun 21, 2021

Hi all,

I finally had a chance to experiment properly with crate_universe, and it looks like it'll be a nice improvement over having to commit the BUILD files manually and manually list out dependencies - crates_from() is great!

One thing I noticed is that the lockfile is considerably bigger than Cargo's - in the modest workspace I'm testing with, Cargo's is about 100k, and the universe one is around 1.8MB. When updating dependencies, the changed lines in git appear to be approximately 10x what they are in the Cargo.lock file.

Would it be practical to store the locked versions in a more compact format in the future?

@dae
Copy link
Contributor Author

dae commented Jun 21, 2021

Sorry, after doing some more digging I found this discussed here: #598 (comment)

If using an existing Cargo.lock file were possible, that would be ideal, as that way one would be ensured that the dependencies used in Bazel exactly match those being used via Cargo/Rust Analyzer.

@illicitonion
Copy link
Collaborator

Yeah, I'm hoping we can get to a point where we're using a Cargo.lock file, probably with an additional magic comment containing a hash in it (which I think is fine - if cargo re-generates it and the magic comment is missing, we know we have work to do, but cargo will happily ignore a comment). If you'd be interested in pushing this forwards, I'd be happy to write up some mentoring guidance!

@dae
Copy link
Contributor Author

dae commented Jun 22, 2021

Bit swamped at the moment, but might take you up on that in the future if no-one else gets to it first. Glad to hear the current lockfile format is more of an implementation detail than a fundamental requirement in any case. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants