Thanks for spotting the typo, I fixed it. There's no error otherwise, just differences in personal preference, understandably I'd rather go with my preferences and I don't care much for trivial changes like these polluting the history. Not trying to deny your contribution, it was easier for me to fix the typo myself than pulling yours and reverting other changes.
Panic due to paths override in .cargo/config
============================================
```
cargo 1.46.0 (149022b1d 2020-07-17)
cargo-outdated v0.9.11
```
---
I use a paths override in `.cargo/config`
```toml
paths = ["../another-crate"]
```
when working on two related crates that reside in different repos. cargo-outdated doesn't like that at all and merely panics:
```console
$ RUST_BACKTRACE=1 cargo outdated -R
thread 'main' panicked at 'no entry found for key', /Users/zmwang/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-outdated-0.9.11/src/cargo_ops/temp_project.rs:654:20
stack backtrace:
0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
1: core::fmt::write
2: std::io::Write::write_fmt
3: std::panicking::default_hook::{{closure}}
4: std::panicking::rust_panic_with_hook
5: rust_begin_unwind
6: core::panicking::panic_fmt
7: core::option::expect_failed
8: cargo_outdated::cargo_ops::temp_project::manifest_paths::manifest_paths_recursive
9: cargo_outdated::cargo_ops::temp_project::manifest_paths::manifest_paths_recursive
10: cargo_outdated::cargo_ops::temp_project::TempProject::from_workspace
11: cargo_outdated::execute
12: cargo_outdated::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```
Apparently related to #188, merged with a quite prophetic comment
> Let's see how that works. Hopefully people won't be using things like index path override that uses a relative path.
Well, people do use things like that...
Personally I don't care about respecting the paths override, a helpful error message saying something along the lines of "you're doing something unsupported in .cargo/config" should be fine. Just don't want to spend twenty minutes trying to make sense of why it's panicking.
Hey, thanks for the catch. A missing long_name is really rare and minor though, I don't think it's worth introducing a breaking change in the API for it. I'd rather just return the empty string when long_name isn't available. Therefore superseded by #36.
codec: fix codec description potential null ptr issue
=====================================================
Codecs may not have `.long_name` initialized.
Issue raised by @Pilyushkin in #34.