Remove is_build: Cell<bool> from ProjectBuilder and introduce a new type Project.
is_build==false <-> ProjectBuilder
is_build==true <-> Project
Also add #[must_use] to ProjectBuilder to confirm its instances are surely consumed by its build() method to produce Project.
The same goes for RepoBuilder.
ProjectBuilder::cargo_process() was removed as its design heavily depended on the internal mutability.
Signed-off-by: NODA, Kai <nodakai@gmail.com>
This flavor of source is intended to behave like a local registry except that
its contents are unpacked rather than zipped up in `.crate` form. Like with
local registries the only way to use this currently is via the
`.cargo/config`-based source replacement currently, and primarily only to
replace crates.io or other registries at the moment.
A directory source is simply a directory which has many `.crate` files unpacked
inside of it. The directory is not recursively traversed for changes, but rather
it is just required that all elements in the directory are themselves
directories of packages.
This format is more suitable for checking into source trees, and it still
provides guarantees around preventing modification of the original source from
the upstream copy. Each directory in the directory source is required to have a
`.cargo-checksum.json` file indicating the checksum it *would* have had if the
crate had come from the original source as well as all of the sha256 checksums
of all the files in the repo. It is intended that directory sources are
assembled from a separately shipped subcommand (e.g. `cargo vendor` or `cargo
local-registry`), so these checksum files don't have to be managed manually.
Modification of a directory source is not the intended purpose, and if a
modification is detected then the user is nudged towards solutions like
`[replace]` which are intended for overriding other sources and processing local
modifications.
This flavor of registry is intended to behave very similarly to the standard
remote registry, except everything is contained locally on the filesystem
instead. There are a few components to this new flavor of registry:
1. The registry itself is rooted at a particular directory, owning all structure
beneath it.
2. There is an `index` folder with the same structure as the crates.io index
describing the local registry (e.g. contents, versions, checksums, etc).
3. Inside the root will also be a list of `.crate` files which correspond to
those described in the index. All crates must be of the form
`name-version.crate` and be the same `.crate` files from crates.io itself.
This support can currently be used via the previous implementation of source
overrides with the new type:
```toml
[source.crates-io]
replace-with = 'my-awesome-registry'
[source.my-awesome-registry]
local-registry = 'path/to/registry'
```
I will soon follow up with a tool which can be used to manage these local
registries externally.
