Feature: Create metafile format for cargo-binstall

[NobodyXu]

Implement #176 (comment)

Signed-off-by: Jiahao XU [email protected]

[NobodyXu]

@passcod Answer to #176 (comment) :

define what the goals for the metafile are. what problems does it solve, what the use will be now and in future

The goals for this PR is to update crates installed by cargo-binstall easily using sth like cargo-tools update -a and for cargo-tools to display currently installed crates and their metadata.

explore a bit the interaction between the metafile and the theoretical manifest+lock described here. are they complementary? conflicting?

If the metafile in this PR is used for global installation and the one in #176 is used for local project only, then I think it is fine.

For local project, you have to install the binary locally too (e.g. $PROJECT/bin and add that to .gitignore) to avoid conflicts anyway.

consider the external use. if an auxillary project like cargo-update wants to use it, could they? if a project like quickinstall, which has its own cli, wants to use it, could they? is that something we want to enable or to discourage?

They definitely can, I think the format is simple enough.
We could also split this into an external crate under a new cargo-binstall org to make it easier for them.

Though for quickinstall it would be easier to just use cargo-binstall and cargo-update probably won't support it for now.

[NobodyXu]

@passcod Answer to #176 (comment) :

I also kinda want to avoid the proliferation of many different files that we write to. ...or maybe we say, let's go and write as many files as we want to, but I'd say let's make our own config folder for all this. there's other stuff we might want to start doing, like keeping caches e.g. for hsts. and having an actual config file, I think that came up once or twice recently

Yep!

I would do that.

[passcod]

Sounds good. I think the plan is then to:

• leave the manifest stuff for now for future design refinement
• your PR and format as-is is good for purpose i think
  • this would be newline separated json, right?
• decide on a name for a new config folder that's put in all the right OS places, I think the dirs crate has those? mostly this is deciding between either binstall or cargo-binstall
  • though in the latter case we could also put it under $CARGO_HOME/.binstall/...? I don't know if that would be a good idea or a bad idea haha
  • the actual work on this can be another PR and just leave a placeholder in this one, if that makes it clearer

[NobodyXu]

this would be newline separated json, right?

Not necessary newline, but simply separate json objects.
When using jq to print it in pretty mode, the output is separated by newline.

I think the dirs crate has those?

Yeah, dirs::config_dir gives us the dir for user configs.

though in the latter case we could also put it under $CARGO_HOME/.binstall/...? I don't know if that would be a good idea or a bad idea haha

This also sounds ok.

I was thinking about $CARGO_HOME/binstall.

the actual work on this can be another PR and just leave a placeholder in this one, if that makes it clearer

Asides from having 1 or 2 more commits, it should be good.

[NobodyXu]

@passcod I ended up picking $CARGO_HOME/binstall/crates-v1.json because by default, we install the binary to $CARGO_HOME/bin, so I think it is more reasonable to put the dir under $CARGO_HOME.

[passcod]

a few suggestions but looks good otherwise