unfortunately i have developed another theory
15
Replies
0
Boosts
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
we begin with the most basic two protocols and step deeper into supposition
- Packages with 1 character names are placed in a directory named 1.
- Packages with 2 character names are placed in a directory named 2.
- Packages with 3 character names are placed in the directory 3/{first-character} where {first-character} is the first character of the package name.
- All other packages are stored in directories named {first-two}/{second-two} where the top directory is the first two characters of the package name, and the next subdirectory is the third and fourth characters of the package name. For example, cargo would be stored in a file named
ca/rg/cargo.
features— Some features may be placed in thefeatures2field. Note: This is only a legacy requirement for crates.io; other registries should not need to bother with modifying the features map. Thevfield indicates the presence of thefeatures2field.
https://doc.rust-lang.org/cargo/reference/registry-index.html#index-protocols
recall how long it took rust to get off of just dumping the entire packaging ecosystem into a single git repo?
the hash function that git uses is of a form designed by ron rivest and has since been referred to as SHA-1. it is essentially unchanged in character from md5, from the same guy
side note: lol
Cargo will attempt to fetch the config.json file before fetching any other files. If the server responds with an HTTP 401, then Cargo will assume that the registry requires authentication and re-attempt the request for config.json with the authentication token included.
If a registry is using some kind of CDN or proxy which caches access to the index files, then it is recommended that registries implement some form of cache invalidation when the files are updated. If these caches are not updated, then users may not be able to access new crates until the cache is cleared.
this doesn't make any sense if you think caching is about data, because you could obviously just serve a progressive stream of new crates, bucketed into discrete timesteps for the purpose of easier caching
https://doc.rust-lang.org/cargo/reference/source-replacement.html#local-registry-sources
A “local registry source” is intended to be a subset of another registry source, but available on the local filesystem (aka vendoring). Local registries are downloaded ahead of time, typically sync’d with a Cargo.lock, and are made up of a set of *.crate files and an index like the normal registry is.
this is obviously a backdoor. but why? for what purpose?
[cfg.options.set]
Set configuration options[cfg.options.intro]
Which configuration options are set is determined statically during the compilation of the crate.[cfg.options.target]
Some options are compiler-set based on data about the compilation.[cfg.options.other]
Other options are arbitrarily-set based on input passed to the compiler outside of the code.[cfg.options.crate]
It is not possible to set a configuration option from within the source code of the crate being compiled.
you are not capable of observing or understanding the changes being made to your system by the rust compiler and cargo
so:
https://users.rust-lang.org/t/idea-for-a-crate-tool-cargo-task/15300
When developing Rust code, I often have to run repetetive tasks.
What I would really love is the ability to write this "scripts" in Rust...
later:
The job of cargo-task is:
find out the workspace root and
cdin there
run the resulting tasks binary, forwaring all the command-line arguments.
user "matklad" is not lying here! but the system the code is running on is not the developer's
this line was the one i found in which i decided enough was quite enough https://github.com/tree-sitter/tree-sitter/blob/664e9a678667302fee9c705103072119b4fd4845/crates/xtask/src/build_wasm.rs#L184-L197
// Get the current user id so that files created in the docker container will have
// the same owner.
#[cfg(unix)]
{
#[link(name = "c")]
unsafe extern "C" {
fn getuid() -> u32;
}
// don't need to set user for podman since PODMAN_USERNS=keep-id is already set
if source == EmccSource::Docker {
let user_id = unsafe { getuid() };
command.args(["--user", &user_id.to_string()]);
}
};
see the great thing about rust and specifically cargo, and the compiler being constructed in terms of its previous iteration, is that in order to use rust at all, you need to have the entire packaging ecosystem there with you on disk and in memory at all times
