Better error message on permission errors
kpcyrd opened this issue · 7 comments
I get the following output:
% cargo watch -- cargo run -- -h
Error: I/O error: Permission denied (os error 13)
there's indeed a folder I can't access:
% find > /dev/null
find: ‘./svntogit-community/sh4d0wup/trunk/pkg’: Permission denied
I assume this error is from cargo-watch (but possibly in the watchexec codebase), I think this should either not be fatal, or the path should be in the error message.
That's fixed upstream (in watchexec library v2+) and will eventually make its way to cargo watch
Sorry to bump into the issue. But wondering why the is no hot-fix release for this well known issue?
Because I haven't had time to work on cargo-watch. You know. The usual reason why things aren't done in an open source project provided to you for free.
Hey @passcod I'm interested in contributing the upgrade for this -- after poking around I found a few things:
- upgrading
cargo-watch2.x breaks everything (as one might expect), as a bunch of things have changed cargo-watch2.x now depends ontokio
It looks like the PR might be quite large in trying to upgrade these libraries and effectively make cargo-watch async...
If I could put a PR together would you be open to such large changes? I'd also probably try and pull in anyhow for error handling as well for convenience in reporting errors, and maybe env_logger or tracing for logging/errors.
There's already a branch to upgrade to watchexec 2.x. Ultimately the main issue is not cargo watch, it's that I don't consider watchexec 2 to be stable or performant enough yet for cargo watch.
(also miette instead of anyhow, tracing subscriber instead of env logger)
That said, if you want to help, then in watchexec what needs to happen is to fix the implementation of the ignore file loader/discovery so it correctly respects ignore files itself, and doesn't exhibit the behaviour of spinning for tens of seconds when started in a large project.
Alternatively there's a massive PR in watchexec where I'm refactoring a bunch of things with some breaking changes. Have a look there at the checklist to see if some chunk of it interests you.
Finally, there's a third area which is programmable filters. That's much more self contained: the upstream project changed a bunch since I prototyped it, so it needs adapting and polishing.
Once those first two areas are stabilised and merged, and possibly the last one released as well, then cargo watch can be upgraded. That step should take a day or so, not a big deal once all the actual work is done.
There's already a branch to upgrade to watchexec 2.x. Ultimately the main issue is not cargo watch, it's that I don't consider watchexec 2 to be stable or performant enough yet for cargo watch.
Ah thanks for noting, this, was not aware of concern about watchexec 2.x
That said, if you want to help, then in watchexec what needs to happen is to fix the implementation of the ignore file loader/discovery so it correctly respects ignore files itself, and doesn't exhibit the behaviour of spinning for tens of seconds when started in a large project.
I see a bunch of issues under ignore loading, but the main one is this one, right?
I'll try and start there -- looks like ignore-filesand filterer need to be changed, based on this comment.
Alternatively there's a massive PR in watchexec where I'm refactoring a bunch of things with some breaking changes. Have a look there at the checklist to see if some chunk of it interests you.
I'm assuming you're referring to this PR. Assuming I'm right, I think I could tackle "Adapt the CLI" but I'm not 100% sure what it means -- I assume it means upgrading clap and refactoring the command structures and stuff like that?
We can continue the discussion in that PR since it's not related to cargo-watch directly.
Yep, that's right :)