iepsen / cmvm Goto Github PK

Download the tar.gz package and install it on the system. As the macOS platform evolves, it requires verifying the best package for the running operating system.

Some conditions:

• Running on macOS 10.13 or later it should fetch the macos-universal.tar.gz package of the desired version
• Running on macOS 10.10 or later it should fetch the macos10.10-universal.tar.gz package of the desired version
• Running on older operating system it should fetch the *darwin* package of the desired version

The use command should set the desired version as current. Currently, cmvm creates a symbolic link to that version so it persists until set to a new one, which could be reviewed if needed.

Possible solution: Create on platform level a set of definitions to match releases. This also simplifies the current implementation (downloading the version json file).

struct SupportedDefinition {
    content_types: Vec<String>,
    name_contains: Vec<String>,
}

fn macos_supported_definition() -> SupportedDefinition {
    SupportedDefinition {
        name_contains: vec![
            "-macos-".to_string(),
            "-macos10.10-".to_string(),
            "-Darwin-".to_string(),
        ],
        content_types: vec!["application/gzip".to_string()],
    }
}

https://docs.rs/anyhow/latest/anyhow/

Use shellscript to install it on path. Reference: https://fnm.vercel.app/install

Remote versions are currently ordered by the release date. It would be good to have ordered by version name.

The list-remote command should fetch versions from Github releases API and print it in a human-readable way, for example:

Available cmake versions:
  3.20.0
  3.20.1
  3.20.2
  3.20.3
  3.20.4
  3.20.5
  3.20.6
  3.21.0
  3.21.1
  3.21.2
  3.21.3
  3.21.4

The list command should print all cmake versions installed by cmvm in a human-readable way. Also important to make clear which is the current version in use. For example:

CMake list managed by cmvm:
   3.16.4
   3.16.9
   3.18.3
 * 3.19.7
   3.20.2

Filter out releases that misses assets without application/json as content_type.

A minimal integration must:

• Run unit tests [reference]
• Generate the binary
• Bump a new tag when merged to master [reference]

Reference:
https://rust-cli.github.io/book/tutorial/packaging.html#getting-your-app-into-package-repositories

• It would be interesting to make the packages from the CI:

• https://doc.rust-lang.org/cargo/guide/continuous-integration.html

• https://github.com/marketplace/actions/build-and-upload-rust-binary-to-github-releases

https://crates.io/crates/log