Support adding rules for specific folders

[repi]

Intro

For our larger Rust monorepo at Embark we have a base deny.toml to disallow certain crates and whitelist licenses for the entire workspace. This works well but we do also have certain more specific projects in subfolders that have additional constraints and that we want to limit more or differently so we want to add support for having specific rules, such as the ban/deny crate list that acts on a specific sub-folder but not the entire workspace.

For example: not allowing rayon crate to be used in our modules/ folder because our crates there are dynamic libraries and either do not support internal parallelism or we don't want them to spawn up their own threadpools.

Potential implementation

Right now I think we are primarily interested in just adding additional bans/deny rules for these folders. Could see a couple of different ways of defining it:

Option 1 - in the main deny.toml

Directly in the current file by specifying paths:

[bans]
multiple_versions = "deny"
deny = [
    { name = "openssl" },
    
    # do not allow rayon to be used in our modules
    { name = "rayon", path = "modules/" }
]

Option 2 - in its own subfolder deny.toml

Could add additional deny.toml files in the subfolders in question that just add the additional rules:

modules/deny.toml

[bans]
deny = [
    # do not allow rayon to be used in our modules
    { name = "rayon", path = "modules/" }
]

Do think I prefer Option 1 for the simplicity of having everything in the same place, but either would work and is related to how we want to evolve the format going forward (#17).

Would be some work to figure out a way to handle and find which dependencies are used by which crates in which folders also for this, that information, that information is not in Cargo.lock

[repi]

Thought of another use case for this, for specific folders in the workspace we may also want to allow to have a different "skip" list, e.g. do not allow duplicate crate versions for the dependencies in the crates in the folder. Less important one though but would be useful.

[TriplEight]

It would be very nice if it were possible to ban licenses for some worspace members, which can also reside in certain subfolders.

[dsully]

+1 - I need to have a centrally managed deny.toml file (outside of any repository), but also allow individual repos to override directives as needed for exceptions. It doesn't sound like there's any way to do this today?

A concrete example:

Enterprise wide deny of LGPL-3 crates, as that is considered a "restricted" license for us.

However, you can apply for an exception to use that specific crate (or package in other ecosystems) and it will be allowed. That exception should be added to the repositories that have approval (via code review/PR), and would override the Enterprise-wide deny for that specific crate.

[workingjubilee]

Agreed. This especially affects compilers for programming languages or DSLs, because the compilers usually have runtime libraries. In my primary case, the runtime gets linked into Rust code, and the compiler gets used to build some additional code that actually controls running the Rust code. These have very different implications for most common software licenses, and that means I created some hacks involving two deny.tomls and shell scripts instead of just using a single deny.toml and GHA, even though one is essentially going to be a superset of the other.

It would be nice if, in a single workspace, I could easily define this subset/superset license relationship without having to duplicate the data.

The alternative is unnecessary amounts of grunt work. Not awful, mind! It's fairly tolerable as hacked-together-with-shell-scripts stuff goes.