"cargo open" that opens a currently-used crate in your $EDITOR

[carols10cents]

A feature I've gotten used to with bundler is bundle open-- it finds the gem that your project is currently using and opens it (actually in your $BUNDLER_EDITOR, but if having another env var for this is undesirable for whatever reason i'd be fine with using $EDITOR).

Usually, I do this in order to quickly take a look at the code that I'm using/calling/depending on. Sometimes I modify the files and rerun with the changes-- I'm not sure what the downsides/implications of doing this with crates are, but it seems like it should be ok. After making modifications when doing this in bundler/rubyland, if I want to reset to the gem's original state, I usually end up removing the gem's entire directory and rerunning bundle install to download it again, but it looks like there's a proposed feature to have a command to reset all modified gems.

Is this something that yinz would accept into cargo? I opened this issue mostly to ask about interest; I'm totally ok with this only ever being a third-party subcommand, or starting as a subcommand and being considered after that point. I'm hoping to try implementing this as a subcommand soon :)

[carols10cents]

Ok, I've got a first attempt going at https://crates.io/crates/cargo-open... it's completely untested right now, I suspect only Registry crates will work right now.

I ended up duplicating a bit of cargo internals because the directory structure is spread throughout and parts are dependent on a whole Config instance being available, which I didn't want to have to do just to get the default of CARGO_HOME, basically. I think I see some refactorings in cargo's source that would make it more possible; I might try those next and see how it feels.

This is related to #1098 since if that existed, I could use the same information.

[alexcrichton]

To bake this into Cargo itself I'd prefer to take the route of something like #1098 where we provide programmatic access to metadata about crates (e.g. the parsed Cargo.toml, where it's cached, etc). That'd certainly make developing this externally quite easy though!