Dirkjan Ochtman
Dirkjan Ochtman
I think I put this in place, not because I have a clear use case but because it made sense for the implementation. I don't see many downsides -- we...
IMO since this is not actionable from our side, closing it makes more sense to me -- it can be reopened (or we can work in a new issue) once...
As a matter of policy, we don't publish advisories without confirmation/agreement from the maintainer, unless the maintainer becomes unresponsive (for 270 days in case of no open issues or 60...
> I don't think this issue warrants an advisory, Why not? If the pre-fork code had one, it seems surprising that this crate wouldn't get one.
> Are there maybe any updates regarding this? It's up to @hdevalence.
> Could you explain the motivation for this change? See #1455. Personally I find that all the layering of `Application`/`Config`/`Runnable` makes it much harder to understand what is happening, and...
> Generally looks OK although there are test failures. > > I assume you want to eventually do another pass to remove it completely? Yeah, will fix the test failures...
This should pass the tests. It is still somewhat ugly because all the `status_*!()` macro calls depend on the terminal component being initialized, which in turn requires a live `Application`...
Fixed the unrelated CI failures in - #1741 Please rebase.
"Failing open" has a bunch of risks too -- the API you're proposing makes it pretty easy to just ignore any errors, which would allow tools running in CI to...