Disable dependency errors (so only the current project is affected)

[parker-codes]

Currently, if you publish/offer a crate and a todo_by expires in the lib code, then I believe it would be an unfixable compilation error for anyone importing the crate.

Is there a way around this? Can we limit the context in which this compiler error shows?

[parker-codes]

Lib authors could perhaps have an optional envar like TODO_BY_LIB=true that would not get included in the crate repo (via git dep) or crates.io assets.

Perhaps there's a Cargo metadata route that can disable all todo_by errors for a lib and its dependencies.

[Emilgardis]

An easy way to do this is

return quote! {
        #[cfg(test)]
        compile_error!(#error_message);
        #[cfg(not(test))]
        pub const _: () = {
            #[deprecated(note = #error_message)]
            const TODO: () = ();
            TODO
        };
    }
    .into();

which would satisfy #2 also. It works by the fact that dependencies don't get passed cfg = test when cargo test is ran.

cargo check -p fail
    Checking fail v0.1.0 (/Users/emil/workspace/todo_by/fail)
warning: use of deprecated constant `add::_::TODO`: TODO by Jan 1, 2022 has passed
 --> fail/src/lib.rs:2:5
  |
2 |     todo_by::todo_by!("2022-01-01");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(deprecated)]` on by default
  = note: this warning originates in the macro `todo_by::todo_by` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: `fail` (lib) generated 1 warning
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s

and when testing a crate which has todo_by

cargo test -p fail
warning: use of deprecated constant `add::_::TODO`: TODO by Jan 1, 2022 has passed
 --> fail/src/lib.rs:2:5
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(deprecated)]` on by default
  = note: this warning originates in the macro `todo_by::todo_by` (in Nightly builds, run with -Z macro-backtrace for more info)

   Compiling fail v0.1.0 (/Users/emil/workspace/todo_by/fail)
warning: `fail` (lib) generated 1 warning
error: TODO by Jan 1, 2022 has passed
 --> fail/src/lib.rs:2:5
  |
2 |     todo_by::todo_by!("2022-01-01");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: this error originates in the macro `todo_by::todo_by` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `fail` due to previous error

[bjorn3]

You could do something like

#[forbid(dead_code)]
#[allow(non_upper_case_globals)]
const TODO_by_Jan_1_2022_has_passed: () = ();

For dependencies cargo will pass --cap-lints allow which silences the dead code warning, but for user crates it will give an error which can't be silenced using #[allow(dead_code)] due to #[forbid(dead_code)].

[parker-codes]

Someone on Reddit brought up the CARGO_PRIMARY_PACKAGE envar.

Here's what it says in the docs:

CARGO_PRIMARY_PACKAGE — This environment variable will be set if the package being built is primary. Primary packages are the ones the user selected on the command-line, either with -p flags or the defaults based on the current directory and the default workspace members. This environment variable will not be set when building dependencies. This is only set when compiling the package (not when running binaries or tests).

So we can attempt to use this to scope to the "current working crate", hopefully. I think this lib should provide a warning instead of a strong error though in order to have reproducible builds.

[parker-codes]

I tested the CARGO_PRIMARY_PACKAGE envar and it's a dead end. I created a dependency tree to test like
todo_by
library_using_todo_by
binary_using_library

The envar was not present in any of these when running the binary or library. It was only present when running the todo_by tests itself. So that defeats the purpose.

Edit: It was present in the todo_by macro when running cargo run in the binary_using_library, which is confusing and doesn't help.

[Emilgardis]

How did you implement it? It should work just fine, as long as you use std::env::var("CARGO_PRIMARY_PACKAGE") and not env!("CARGO_PRIMARY_PACKAGE")

[parker-codes]

Yep, this is what I used. I logged out the value along with the project name so I would know which depth the value came from. All said the same thing.

I can try again though.