carols10cents / cargo-open Goto Github PK

In main.rs, add unit tests for the cargo_dir function that checks that it returns the correct directory for different kinds of crates that have been installed, like:

• A crate specified with * as its version
• A crate specified with a particular version
• A crate installed from github
• A crate installed from a local path
• A crate that we have a local override set up for

This may require setting up some infrastructure similar to what cargo does for its tests in order to be able to create temporary directories that contain different kinds of projects.

In main.rs, add a unit test for the cargo_dir function that checks that it panics if we have specified a new crate in the Cargo.toml file but have not yet run any command that would fetch that crate's source to our local filesystem.

Use the existing test marked should_panic for an example of how to make a test check that a function panics.

I doubt that this test will pass currently! Eventually, I'd like this to panic with a message like "Cannot open crate whatever because it is not a dependency of the current project`" or similar.

When used with sudo it works. Other cargo plugins install without sudo. I can't see why sudo should be necessary. Without sudo I get:

$ cargo install cargo-open --verbose
    Updating registry `https://github.com/rust-lang/crates.io-index`
failed to compile `cargo-open v0.3.0`, intermediate artifacts can be found at `/tmp/target-install`

Caused by:
  unable to get packages from source

Caused by:
  Permission denied (os error 13)

In main.rs, add a unit test for the cargo_dir function that checks that it panics if we have specified a new crate in the Cargo.toml file but have not yet run any command that would fetch that crate's source to our local filesystem.

Use the existing test marked should_panic for an example of how to make a test check that a function panics.

As I write this up, I'm seeing that it would be easier if a function to read the Cargo.toml contents was extracted from the cargo_dir function and, instead, cargo_dir took the contents of Cargo.toml as an argument. That would make it easier to pass different Cargo.toml contents in for a unit test, so that should be part of this issue and should be done before adding the test.

I'd accept a PR that adds this test even if it fails, or if it fails with a weird error message! I'm not sure if I've coded things in such a way as to reuse existing cargo knowledge or not. Eventually I'd like this to panic with a message like "This crate has not been fetched yet; please run cargo install" first.

Bonus points if you change the code to make the test pass!

In main.rs, add a unit test for the cargo_dir function that checks that it returns the correct source code directory for a crate that is a dependency of a crate that is a top-level dependency.

For example, clap is one of this project's top-level dependencies, and ansi_term is one of clap's dependencies. So if we run cargo_dir("ansi_term") in the context of this project, we should get the correct source code directory for ansi_term even though it's not in the Cargo.toml file directly.

I haven't used multirust, so I'm not sure how it interacts with cargo and if this is even something cargo-open needs to be concerned about. But it was something that came to mind when I was trying to think about all the ways crates could be installed.

Could you explain me more, please? I don't have much experience with Rust =)

In main.rs, add a unit test for the cargo_dir function that checks that it panics if we try to run this command in a directory that doesn't have a Cargo.toml and thus would have no idea where to look to figure out where that crate might be!

Use the existing test marked should_panic for an example of how to make a test check that a function panics.

I doubt that this test will pass currently! Eventually, I'd like this to panic with a message like "Cannot find Cargo.toml file in the current directory" or similar.

When repetitively running cargo test, occasionally some of the tests (usually tests::prefer_visual_over_editor) will fail. The reason for this is inconsistent, and seems to me like a potential data race situation. Examples:

---- tests::check_env_editor stdout ----
        thread 'tests::check_env_editor' panicked at 'assertion failed: `(left == right)` (left: `"some_editor"`, right: `"some_cargo_editor"`)', src/main.rs:117

---- tests::prefer_visual_over_editor stdout ----
        thread 'tests::prefer_visual_over_editor' panicked at 'Cannot find an editor. Please specify one of $CARGO_EDITOR, $VISUAL, or $EDITOR and try again.', src/libcore/option.rs:335

---- tests::prefer_visual_over_editor stdout ----
        thread 'tests::prefer_visual_over_editor' panicked at 'assertion failed: `(left == right)` (left: `"some_visual"`, right: `"some_cargo_editor"`)', src/main.rs:153

$ cargo install cargo-open
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading cargo-open v0.3.0
 Downloading clap v2.19.1
 Downloading rustc-serialize v0.3.22
 Downloading num_cpus v1.2.0
 Downloading libc v0.2.18
 Downloading tar v0.4.9
 Downloading gcc v0.3.39
 Downloading cmake v0.1.19
 Downloading rand v0.3.15
 Downloading unicode-segmentation v0.1.3
   Compiling bitflags v0.7.0
   Compiling openssl-probe v0.1.0
   Compiling unicode-width v0.1.3
   Compiling rustc-serialize v0.3.22
   Compiling strsim v0.5.2
   Compiling gcc v0.3.39
   Compiling glob v0.2.11
   Compiling matches v0.1.4
   Compiling regex-syntax v0.3.9
   Compiling unicode-bidi v0.2.3
   Compiling winapi v0.2.8
   Compiling cfg-if v0.1.0
   Compiling bitflags v0.1.1
   Compiling ansi_term v0.9.0
   Compiling libc v0.2.18
   Compiling unicode-normalization v0.1.2
   Compiling crossbeam v0.2.10
   Compiling net2 v0.2.26
   Compiling memchr v0.1.11
   Compiling term_size v0.2.1
   Compiling unicode-segmentation v0.1.3
   Compiling idna v0.1.0
   Compiling aho-corasick v0.5.3
   Compiling winapi-build v0.1.1
   Compiling num_cpus v1.2.0
   Compiling utf8-ranges v0.1.3
   Compiling lazy_static v0.2.2
   Compiling pkg-config v0.3.8
   Compiling psapi-sys v0.1.0
   Compiling ws2_32-sys v0.2.1
   Compiling advapi32-sys v0.2.0
   Compiling filetime v0.1.10
   Compiling vec_map v0.6.0
   Compiling rand v0.3.15
   Compiling miniz-sys v0.1.7
   Compiling clap v2.19.1
   Compiling tar v0.4.9
   Compiling libz-sys v1.0.7
   Compiling url v1.2.3
   Compiling tempdir v0.3.5
   Compiling openssl v0.7.14
   Compiling flate2 v0.2.14
   Compiling openssl-sys-extras v0.7.14
   Compiling openssl-sys v0.7.17
   Compiling cmake v0.1.19
   Compiling curl-sys v0.2.5
   Compiling log v0.3.6
   Compiling kernel32-sys v0.2.2
   Compiling fs2 v0.2.5
   Compiling term v0.4.4
   Compiling thread-id v2.0.0
   Compiling thread_local v0.2.7
   Compiling miow v0.1.3
   Compiling libgit2-sys v0.4.6
   Compiling regex v0.1.80
   Compiling toml v0.2.1
   Compiling libssh2-sys v0.1.41
   Compiling git2 v0.4.4
   Compiling env_logger v0.3.5
   Compiling semver-parser v0.6.1
   Compiling docopt v0.6.86
   Compiling semver v0.5.1
   Compiling curl v0.3.11
   Compiling crates-io v0.4.0
   Compiling git2-curl v0.5.0
   Compiling cargo v0.14.0
   Compiling cargo-open v0.3.0
error[E0425]: unresolved name `cargo::ops::load_lockfile`
  --> /home/jgp/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-open-0.3.0/src/main.rs:66:30
   |
66 |     let resolved      = try!(cargo::ops::load_lockfile(&lock_path, &src_id)).unwrap();
   |                              ^^^^^^^^^^^^^^^^^^^^^^^^^ unresolved name

error: aborting due to previous error

error: failed to compile `cargo-open v0.3.0`, intermediate artifacts can be found at `/tmp/cargo-install.QPxBb9k1TMHL`

Caused by:
  Could not compile `cargo-open`.

To learn more, run the command again with --verbose.

Rust installed with rustup.rs on CentOS 7.

$ rustc -Vv
rustc 1.13.0 (2c6933acc 2016-11-07)
binary: rustc
commit-hash: 2c6933acc05c61e041be764cb1331f6281993f3f
commit-date: 2016-11-07
host: x86_64-unknown-linux-gnu
release: 1.13.0

Since std::process::Command expects a program, and only a program, in Command::new.

I don't really want to have to parse args out of $EDITOR myself, it'd be nice if there was a way to do this... need to do research into what the intended behavior of Command is.