Use Project as a generic bound and move data to constants - #136
Use Project as a generic bound and move data to constants#136DanielEScherzer wants to merge 10 commits into
Project as a generic bound and move data to constants#136Conversation
The parts of `Project` that need to hold different logic for different projects, and the parts of `Project` that need to be dyn compatible, are currently both held in the `Project` trait. Introduce a `ProjectDisplayConfig` struct to hold the parts that need to be dyn compatible and use it in `ProjectData`.
Rather than using boxed dyn-compatible values, use generics, in preparation for using associated constants in the `Project` trait.
Switch the `name()`, `url_path()`, `is_homepage()`, and `is_versionless()` functions to associated constants `NAME`, `URL_PATH`, `IS_HOMEPAGE`, and `IS_VERSIONLESS` respectively.
Use it to fetch the Oid of the last commit to a specific revision specification in a git repository.
Now that version logic is part of the `Project` trait and thus specific to a project, no need to use fancy detection logic.
Rather than a method
To simplify adding new ones in the future
|
CC @Kobzol pub struct CratesIo;
impl Project for CratesIo {
const NAME: &'static str = "crates.io";
const URL_PATH: &'static str = "crates.io";
const IS_VERSIONLESS: bool = true;
const REPO_URL: &'static str = "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/rust-lang/crates.io.git";
fn get_versions(repo: &Repository) -> Result<Vec<VersionTag>, Box<dyn std::error::Error>> {
Ok(vec![VersionTag {
name: String::from("Nightly"),
version: Version::new(1, 0, 0),
raw_tag: String::from("main"),
commit: revision_latest_commit(repo, "HEAD"),
in_progress: true,
}])
}
}and then the addition to main() "crates.io" => CratesIo, |
|
Could you maybe share some motivation for why you want to do this? Pretty much everything here seems more complicated to me, and I don't see any benefits. |
I didn't have a chance to review #125 or I would have said something then Some of this is useful on its own, #135 and #137 I also don't think this is more complicated, though maybe that is just me |
|
So I was thinking that we could load some of the simpler, versionless projects from a TOML file (or a set of TOML files), so that we don't need to provide a new trait impl and modify code when adding a new project. Then the function would be needed (I'd just change the str ref to |
I figured that moving things to constants like this PR will do makes the new trait impls much simpler
which function is this? Or do you mean that the various getter functions would be needed because the data wouldn't be known at compile time? |
Yeah. Also I think that in general functions + dyn are the simpler solution here, there's no real need for generics IMO. |
2 participants
No description provided.