-
Notifications
You must be signed in to change notification settings - Fork 32
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Middle-ground vendoring option using a local registry (#46)
Summary: The problem is a goldilocks one. 1. `vendor = false` is quick & easy to manage deps & buckify, but pretty bad day to day. - Doesn't work offline as buck2 issues HEAD requests constantly - Terrible DX annoyance with "too many open files" errors due to buck trying to download 1000 crates at once. The standard start to your day looks like "run buck2 build about 15 times until by random chance the scheduler manages to get past those errors" - Those crates get downloaded again, and again, and again - `reindeer buckify` takes 2 seconds or so. Pretty convenient. 2. `[vendor] ...` is slow to manage deps & buckify. - Neat for small projects - Also probably neat for Meta with y'all's funky EdenFS etc. - But middle ground is bad - Middle = `vendor` directory of 1000 crates, 1.2 GB, 50k source files. Mostly from dupes of the windows crates which can't be pinned to one single version etc. - `reindeer vendor` takes 35 seconds - `reindeer buckify` takes 20 seconds - `git status` takes 150ms - The vendor folder wrecks git performance simply by its existence. - Build experience is perfect, works offline, etc. I think we need a solution for the middle ground: - `vendor = "local-registry"`, using https://github.com/dhovart/cargo-local-registry - `reindeer vendor` ultimately just writes a bunch of .crate files into vendor/, which are just gzipped tarballs - .crate files stored in git, but using git-lfs if you like. Suddenly `windows-0.48.0.crate` is just a blob. Your diffs are much simpler when you modify deps. Etc. - Some buck2 rule to extract them. (There is no prelude rule that can do this with `strip_prefix` and `sub_targets` support, but prelude's `extract_archive` could probably have that added.) Outcomes: - Offline works (~~although doesn't handle cargo `package = { git = "..." }` deps yet~~). - `reindeer vendor` and `reindeer buckify` both take 2 seconds - `git status` takes 20ms - Buck builds are a compromise, but a pretty great one. It still has to extract the tarballs when you want to build things. But at least buck won't ever actually extract `windows-0.48.0.crate` on linux, and you only pay for what you build. - The DX annoyance factor during builds is back to zero. No more too many open files errors. - DX annoyance when updating deps is acceptable. Problems: - Relies on https://github.com/dhovart/cargo-local-registry being installed. Note however this is a single-file binary. I think if you rewrote it without the dependency on the `cargo` crate it would be maybe a 2-file crate. And we could use it as a library. - I think storing the local registry's `index` folder (nested `ab/ ac/ ah/ ...` folders) might be a little bit annoying if you're making concurrent edits on different branches. But you can always regenerate. Pull Request resolved: #46 Reviewed By: zertosh Differential Revision: D67925711 Pulled By: dtolnay fbshipit-source-id: 2203d939cf4381c722abf6ea88e3acaf86a30c24
- Loading branch information
1 parent
018b70d
commit 8f90c1f
Showing
8 changed files
with
260 additions
and
75 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.