`ship` command fails with a custom CARGO_INSTALL_ROOT

[neslinesli93]

Description cargo-liner tries to read the file .crates.toml from the cargo home directory, and exits with error when said file is missing:

 DEBUG cargo_liner::config::cargo_crates_toml > Reading Cargo-installed packages from "/github/home/rust/.cargo/.crates.toml"...
 ERROR cargo_liner                            > No such file or directory (os error 2)

However cargo allows to specify a custom installation directory for binaries, using the install.root property or the $CARGO_INSTALL_ROOT env variable. That folder is then used to store the .crates.toml file as explained in the docs.

Right now, the file needs to be copied manually from $CARGO_INSTALL_ROOT to $CARGO_HOME before launching cargo liner ship

Expected behavior cargo-liner should search for the .crates.toml file in the install.root folder (don't know if it's possible tho)

[PaulDance]

Hi @neslinesli93! Thanks for the report.

As this is controlled by an official configuration element of Cargo, this is indeed a legitimate use case. Just out of curiosity, which one are you actually using: $CARGO_INSTALL_ROOT or (inclusively) install.root?

I've looked a bit into how I would solve this:

• Reading $CARGO_INSTALL_ROOT is trivial.
• Parsing the Cargo config file manually seems tedious, as there are a lot of tables. It should be possible to ignore other tables and just get to install.root though.
• cargo-config2 exists just for that, but it does not expose access to the install table.
• There is a currently-unstable official Cargo command that is similar: cargo config. Using it would therefore mean either requiring a nightly toolchain to be used through cargo +nightly liner [...] (I think), or internally calling Cargo with RUSTC_BOOTSTRAP=1 set (bit of a hack). It handles environment variables as well: running RUSTC_BOOTSTRAP=1 CARGO_INSTALL_ROOT=/tmp cargo -Z unstable-options config get --format json-value install.root successfully displays "/tmp" and having install.root set in $CARGO_HOME/config.toml or any .cargo/config.toml (in)directly under the current directory works too, while preserving the preference over $CARGO_INSTALL_ROOT.

For now, I think the last option is the best as it supports all possible use cases of these configuration elements and is by far the simplest. Do you know of any other way to change where .crates.toml is stored? I've searched briefly in the Cargo documentation, but it seems to be mentioned only for install.root.

Cheers, Paul.

[neslinesli93]

Thanks for the super quick response! Right now I'm using the env variable, $CARGO_INSTALL_ROOT. And I agree that the last solution would be the best one, but requiring the nightly toolchain seems a bit too opinionated/wrong, but I don't know...

Did you try all the possibilities described here to see if .crates.toml is created over there as well?

[PaulDance]

No problem :smiley: Yes, for now, I think I'll try it with RUSTC_BOOTSTRAP=1 first because it simply seems to work just fine and it is only for reading one file anyway. There might be bit of breakage in the future however, we'll have to see.

In the docs you linked, there is a precedence list for the determination of the installation root directory. As of now, only the last two possibilities are supported by using the home crate. With the current issue fixed, the two above will be supported as well. Apart from that, I don't see any other mention of the file, it only seems to be created under the installation root.

I forgot to mention it, but as a temporary workaround, you can use the --skip-check option in the meantime: reading the .crates.toml file is only done during the version check in order to determine which packages need an update, so if you skip it, no file read will be attempted and the installation should proceed successfully.

[PaulDance]

Ah no, scratch what I just said, the file is read every time... This is somewhat inconsistent with the way the documentation of the option is worded.

I think I'll work on a fix specifically for that before fixing the current issue by making sure said option also controls the reading and parsing of the file: when the option is given, it is only used to display "Updating" instead of "Installing" in the logs when the package is already installed, therefore not that useful; I can definitely live without that small display distinction as the option was originally kind of meant for going back to the previous, simpler behavior and thus working around potential future bugs -- this is one of them.

[PaulDance]

@neslinesli93 This should now be fixed, so you can update your installation with cargo install --git https://github.com/PaulDance/cargo-liner.git until I publish a proper patch release with #5 as well, probably some time tomorrow.

[neslinesli93]

Thank you @PaulDance !

[PaulDance]

Fix released as part of v0.4.1.