Programmatic init() with full detection, but without the Cargo feature?

[abesto]

Hi! concolor is really cool, and I want us to start using it! Unfortunately in our large buck2-managed monorepo cargo features are completely unified. This means internal libraries can't depend on a non-auto version without completely losing auto everywhere.

Would you consider exposing a way to programatically (re-)trigger detection as if the auto feature was enabled? That would let us integrate this in a central place used only in our CLIs, and keep the dependency default-features = false (and so safe to use in internal libraries, without fear of unintentionally "poisoning" builds).

(If you’re concerned about this undermining the intended usage of concolor, I think an approach like Tokio's unstable features could work here: https://docs.rs/tokio/latest/tokio/#unstable-features)

[epage]

As a heads up, when I landed on the design for anstream, it ended up completely negating the need for concolor and have basically put this crate on life support without a strong justification.

As for your this issue, the details aren't too clear to me.

• Why is a library not wanting auto a problem for libraries that do?
• What do you mean by programmatically re-triggering detection as-if auto was enabled and what would that look like? Nothing is directly condition on the auto feature but it is used to pull in all of the other features.

[abesto]

As a heads up, when I landed on the design for anstream, it ended up completely negating the need for concolor and have basically put this crate on life support without a strong justification.

Oops, that's good to know, not sure how I missed that. I guess that kinda makes this a non-issue: starting adoption of a library that's already on life-support sounds like a terrible idea.

Still, answers in case they're useful somehow:

Why is a library not wanting auto a problem for libraries that do?

Let me expand on "cargo features are completely unified". There's one single place where external dependencies (i.e. OSS crates from crates.io) are defined in our monorepo. This means it's impossible for one internal library to have auto, and another library to not have auto (or another binary for that matter, there's no distinction there). This in turn means we can have a sequence of events:

1. An external library libA we use currently depends on concolor (correctly, with default features disabled)
2. We import concolor with auto enabled for direct use in internal CLIs
3. This triggers a change in the behavior of libA, which changes the behavior of any CLI using libA, without any change in CLI code

Cue much debugging, confusion, and gnashing of teeth, engineers shouting "SpOoKy AcTiOn at a distance!"

What do you mean by programmatically re-triggering detection as-if auto was enabled and what would that look like? Nothing is directly condition on the auto feature but it is used to pull in all of the other features.

I meant: I'd like to be able to call something like concolor::reinit_with_all_detection_features(), and have it behave as if all the features checked here were enabled.

Edit: there's potentially better ways of achieving what I wanted, but given the status of concolor, probably not worth spending cycles on.

[epage]

You likely missed it because we hadn't done comms on it yet. We were giving it a period if rest before moving further with it.

#47 is the official announcement