Fixes (#118)

* General docs cleanup
* Allow `list` to use config targets
* Allow specifying default license acceptance
* Update docs with [licenses.default]
* Update CHANGELOG

CHANGELOG.md

@@ -6,6 +6,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 <!-- next-header -->
 ## [Unreleased] - ReleaseDate
+### Added
+- Resolved [#116](https://github.com/EmbarkStudios/cargo-deny/issues/116) by adding the `[licenses.default]` field, which allows you to configure how to handle licenses that don't match any other predicate
+- Resolved [#117](https://github.com/EmbarkStudios/cargo-deny/issues/117) by allowing the `list` subcommand to also use the normal configuration used by the `check` subcommand. Only the `targets` field is used, to determine which crates have their licenses listed.
+
 ## [0.6.1] - 2020-01-24
 ### Added
 - Added `[advisories.yanked]` field in [PR#114](https://github.com/EmbarkStudios/cargo-deny/pull/114) for linting yanked crates.

docs/src/README.md

@@ -1,8 +1,7 @@
 # [cargo-deny](https://github.com/EmbarkStudios/cargo-deny)
 
-cargo-deny is a cargo plugin that lets you lint your project's dependency
-graph to ensure all your dependencies conform to your expectations and
-requirements.
+cargo-deny is a cargo plugin that lets you lint your project's dependency graph 
+to ensure all your dependencies conform to your expectations and requirements.
 
 ## Quickstart
 
@@ -15,24 +14,24 @@ cargo install cargo-deny && cargo deny init && cargo deny check
 
 ## Command Line Interface
 
-cargo-deny is primarily intended to be used as a CLI, see
-[Command Line Tool](cli/index.html) for the available commands and their options.
+cargo-deny is intended to be used as a [Command Line Tool](cli/index.html),
+see the link for the available commands and options.
 
 ## Checks
 
-cargo-deny supports several classes of checks, see the
-[Checks](checks/index.html) for the available checks and their configuration
-options.
+cargo-deny supports several classes of checks, see [Checks](checks/index.html) 
+for the available checks and their configuration options.
 
 ## API
 
 cargo-deny is primarily meant to be used as a cargo plugin, but a majority of
-its functionality is within a library whose docs you view on
+its functionality is within a library whose docs you may view on
 [docs.rs](https://docs.rs/cargo-deny)
 
 ## GitHub Action
 
-For GitHub projects one can run cargo-deny automatically as part of continous integration using a GitHub Action:
+For GitHub projects, one can run cargo-deny automatically as part of continous 
+integration using a GitHub Action:
 
 ```yaml
 name: CI
@@ -45,4 +44,6 @@ jobs:
     - uses: EmbarkStudios/cargo-deny-action@v0
 ```
 
-For more information, see [`cargo-deny-action`](https://github.com/EmbarkStudios/cargo-deny-action) repository.
+For more information, see 
+[`cargo-deny-action`](https://github.com/EmbarkStudios/cargo-deny-action) 
+repository.

docs/src/checks/README.md

@@ -16,7 +16,8 @@ Checks for specific crates in your graph, as well as duplicates.
 ## [advisories](advisories/index.html)
 
 Checks advisory databases for crates with security vulnerabilities, or that
-have been marked as `Unmaintained`.
+have been marked as `Unmaintained`, or which have been yanked from their source
+registry.
 
 ## [sources](sources/index.html)
 

docs/src/checks/advisories/README.md

@@ -12,10 +12,9 @@ cargo deny check advisories
 ## Use Case - Detecting security vulnerabilities
 
 Security vulnerabilities are generally considered "not great" by most people, 
-luckily rust has a great
-[advisory database](https://github.com/RustSec/advisory-db) which cargo-deny 
-can use to check that you don't have any crates with (known) security 
-vulnerabilities.
+luckily, Rust has a great [advisory 
+database](https://github.com/RustSec/advisory-db) which cargo-deny can use to 
+check that you don't have any crates with (known) security vulnerabilities.
 
 The database can be changed to use your own as well, as long as it follows the
 same format.

docs/src/checks/bans/README.md

@@ -32,7 +32,7 @@ The larger your project and number of external dependencies, the likelihood that
 you will have multiple versions of the same crate rises. This is due to two
 fundamental aspects of the Rust ecosystem.
 
-1. Cargo's dependency resolution, tries to solve all  the version constraints 
+1. Cargo's dependency resolution tries to solve all the version constraints 
 to a crate to the same version, but is totally ok with using [multiple 
 versions](https://stephencoakley.com/2019/04/24/how-rust-solved-dependency-hell)
 if it is unable to.
@@ -42,31 +42,35 @@ mention different philosophies on dependecies and how often (or not) they should
 be updated, so it is inevitable that crates will not always agree on which
 version of another crate they want to use.
 
-This tradeoff of allowing multiple version so of the same crate is one of the
+This tradeoff of allowing multiple version of the same crate is one of the
 reasons that cargo is such a pleasant experience for many people new to Rust,
 but as with all tradeoffs, it does come with costs.
 
-1. More packages must be fetched, which tends to impact CI more than devs.
-1. Compile times increase, which impacts CI and devs.
-1. Target directory size increases, which can impact devs.
-1. Final binary size will also tend to increase, which can impact users.
+1. More packages must be **fetched**, which especially impacts CI, as well as 
+devs.
+1. **Compile times** increase, which impacts CI and devs.
+1. **Target directory size** increases, which can impact devs, or static CI 
+environments.
+1. Final **binary size** will also tend to increase, which can impact users.
 
 Normally, you will not really notice that you have multiple versions of the
 same crate unless you constantly watch your build log, but as mentioned above,
 it **does** introduce papercuts into your workflows.
 
 The intention of duplicate detection in cargo-deny is not to "correct" cargo's
 behavior, but rather to draw your attention to duplicates so that you can make
-and informed decision about how to handle the situation.
+an informed decision about how to handle the situation.
 
 * Maybe you want to open up a PR on a crate to use a version of the duplicate
 that is aligned with the rest of the ecosystem.
 * Maybe the crate has actually already been updated, but the maintainer hasn't
-published a new version yet and you can ask them to publish a new one.
-* Maybe even though the versions are supposedly incompatible according to
-semver, they actually aren't, and you temporarily introduce a `[patch]` to
-force the crate to use a particular version.
+published a new version yet, and you can ask if they can publish a new one.
+* Maybe, even though the versions are supposedly incompatible according to
+semver, they actually aren't, and you can temporarily introduce a `[patch]` to
+force the crate to use a particular version for your entire workspace.
 * Sometimes having the "latest and greatest" is not really that imporant for
-every version, and you can just downgrade to a version that matches one of
-the duplicates instead.
-
+every version, and you can just specify a lower version in your own project that
+matches the transitive contraint(s).
+* And finally, you don't care about a particular case of multiple versions, so
+you just tell cargo-deny to ignore one or more of the specific versions, and the
+situation will eventually resolve itself.

docs/src/checks/bans/cfg.md

@@ -63,10 +63,10 @@ care.
 ### The `skip` field (optional)
 
 When denying duplicate versions, it's often the case that there is a window of
-time where you must wait for eg. PRs to be accepted and new version published,
-before 1 or more duplicates are gone. The `skip` field allows you to temporarily
-ignore a crate during duplicate detection so that no errors are emitted, until
-it is no longer need.
+time where you must wait for, for example, PRs to be accepted and new version
+published, before 1 or more duplicates are gone. The `skip` field allows you to
+temporarily ignore a crate during duplicate detection so that no errors are 
+emitted, until it is no longer need.
 
 It is recommended to use specific version constraints for crates in the `skip`
 list, as cargo-deny will emit warnings when any entry in the `skip` list no
@@ -80,7 +80,7 @@ versions of certain crates while in alpha or beta, or on the opposite end of
 the specturm, a crate is using severely outdated dependencies while much of the 
 rest of the ecosystem has moved to more recent versions. In both cases, it can 
 be quite tedious to explicitly `skip` each transitive dependency pulled in by 
-that crate that clashes with your other dependencies, which is where `skip-tree` 
+that crate that clashes with your other dependencies, which is where `skip-tree`
 comes in.
 
 `skip-tree` entries are similar to `skip` in that they are used to specify a 
@@ -91,4 +91,5 @@ the `skip` field.
 
 Note that by default, the `depth` is infinite.
 
-`skip-tree` is a very big hammer at the moment, and should be used with care.
+**NOTE:** `skip-tree` is a very big hammer at the moment, and should be used 
+with care.

docs/src/checks/cfg.md

@@ -23,13 +23,13 @@ fuchsia-cprng = "0.1.1"
 
 But unless you are actually targetting `x86_64-fuchsia` or `aarch64-fuchsia`,
 the `fuchsia-cprng` is never actually going to be compiled or linked into your
-project, so checking it pointless for you.
+project, so checking it is pointless for you.
 
-The `targets` field allows you to specify one or more targets which you actually
-build for. Every dependency link to a crate is checked against this list, if
-none of the listed targets satisfy the target constraint, the dependency link
-is ignored. If a crate has no dependency links to it, it is not included in
-the crate graph that checks are executed against.
+The `targets` field allows you to specify one or more targets which you 
+**actually** build for. Every dependency link to a crate is checked against this 
+list, and if none of the listed targets satisfy the target constraint, the 
+dependency link is ignored. If a crate has no dependency links to it, it is not 
+included into the crate graph that the checks are executed against.
 
 #### The `triple` field
 
@@ -45,11 +45,11 @@ configuration check for that target will be limited to only the raw
 Rust `cfg()` expressions support the [`target_feature = 
 "feature-name"`](https://doc.rust-lang.org/reference/attributes/codegen.html#the-target_feature-attribute)
 predicate, but at the moment, the only way to actually pass them when compiling 
-is to use the `RUSTFLAGS` environment variable. The features field allows you
-to specify 1 or more `target_feature`s you plan to build with. At the time of
-this writing, cargo-deny does not attempt to validate that the features you
-specify are actually valid for the target triple, but this is
-[planned](https://github.com/EmbarkStudios/cfg-expr/issues/1).
+is to use the `RUSTFLAGS` environment variable. The `features` field allows you
+to specify 1 or more `target_feature`s you plan to build with, for a particular
+target triple. At the time of this writing, cargo-deny does not attempt to 
+validate that the features you specify are actually valid for the target triple, 
+but this is [planned](https://github.com/EmbarkStudios/cfg-expr/issues/1).
 
 ### The `[licenses]` section
 

docs/src/checks/licenses/README.md

@@ -2,7 +2,7 @@
 
 The licenses check is used to verify that every crate you use has license terms
 you find acceptable. cargo-deny does this by evaluating the license requirements
-specified by each crate against the [configuration](cfg.md) you've specified to 
+specified by each crate against the [configuration](cfg.md) you've specified, to
 determine if your project meets that crate's license requirements.
 
 ```bash
@@ -14,31 +14,30 @@ cargo deny check licenses
 ### SPDX
 
 cargo-deny uses [SPDX license expressions][SPDX] as the source of truth for the 
-license requirements of a crate. It should be noted however that cargo-deny does
-**not** (currently) exhaustively search the entirety of the source code for 
-every crate to find every possible license that could be attributed to the crate 
-as there are a ton of edge cases to that approach.
+license requirements of a crate. Note however, that cargo-deny does **not** 
+(currently) exhaustively search the entirety of the source code of every crate 
+to find every possible license that could be attributed to the crate, as there 
+are a ton of edge cases to that approach.
 
 cargo-deny rather assumes that each crate correctly defines its license 
-requirements, but it also has a mechanism for manually specifying the license 
-requirements for crates in the rare circumstances cargo-deny cannot be 
-automatically obtained.
+requirements, but it provides a mechanism for manually specifying the license 
+requirements for crates in the, from our experience, rare circumstance that they
+cannot be gathered automatically.
 
 ### Expression Source Precedence
 
-The source of the SPDX expression used to evaluate the crate by is obtained
-in the following order.
+The source of the SPDX expression used to evaluate the crate by is obtained in 
+the following order.
 
-1. If the crate in question has a [Clarification](cfg.md#the-clarify-field)
+1. If the crate in question has a [Clarification](cfg.md#the-clarify-field-optional)
 applied to it, and the source file(s) in the crate's source still match, the
 expression from the clarification will be used.
-1. The [`license`][cargo-md]
-field from the crate's Cargo.toml manifest will be used if it exists.
-1. The [`license-file`][cargo-md]
-field, as well as **all** other `LICENSE(-*)?` files will be parsed to determine
-the SPDX license identifier, and then all of those identifiers will be joined
-with the `AND` operator, meaning that you must accept all of the licenses
-detected.
+1. The [`license`][cargo-md] field from the crate's Cargo.toml manifest will be 
+used if it exists.
+1. The [`license-file`][cargo-md] field, as well as **all** other `LICENSE(-*)?` 
+files will be parsed to determine the SPDX license identifier, and then all of 
+those identifiers will be joined with the `AND` operator, meaning that you must 
+accept **all** of the licenses detected.
 
 ### Evaluation Precedence
 
@@ -49,14 +48,15 @@ accepted or rejected is as follows:
 1. A license specified in the `allow` list is **always accepted**.
 1. If the license is considered
 [copyleft](https://en.wikipedia.org/wiki/Copyleft), the
-[`[licenses.copyleft]`](cfg.md#the-copyleft-field) configuration determines its
-status
+[`[licenses.copyleft]`](cfg.md#the-copyleft-field-optional) configuration 
+determines its status
 1. If the license is [OSI Approved](https://opensource.org/licenses) or
 [FSF Free/Libre](https://www.gnu.org/licenses/license-list.en.html), the
-[`[licenses.allow-osi-fsf-free]`](cfg.md/#the-allow-osi-fsf-free-field) 
-configuration determines its status
-1. If the license does not match any of the above criteria, it is implicitly 
-**rejected**.
+[`[licenses.allow-osi-fsf-free]`](cfg.md#the-allow-osi-fsf-free-field-optional) 
+configuration determines its status, if it is `neither` the check continues
+1. If the license does not match any of the above criteria, the 
+[`[licenses.default]`](cfg.md#the-default-field-optional) configuration 
+determines its status
 
 [SPDX]: https://spdx.github.io/spdx-spec/appendix-IV-SPDX-license-expressions/
 [cargo-md]: https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata