Use watchexec API rather than calling cargo-watch

[passcod]

What a wonderful and comprehensive project! Surprised I didn't know of it before...

I noticed that the watch implementation calls to the cargo-watch tool externally. That works, but what may be more efficient and less fragile (if I break the cargo-watch cli interface, there may not be a way for you to notice until you see the breakage, possibly only through reports) would be to use the watchexec library interface (which is what cargo-watch itself does).

That would probably reduce some duplication as you'd be able to use the native settings struct, remove some overhead, possibly make it work better out of the box (not sure how you're packaging... are you shipping the cargo-watch binary along with cargo-make?), and of course if the interface changes you'll get errors at compile time.

However, you may need to reimplement things that cargo-watch does (it might be possible to export some of those from the cargo-watch crate, if that helps).

In the end it's your trade-offs, your choice, of course :) I'm certainly not pushing against your current method of using cargo-watch, that's perfectly valid, just pointing out a possible improvement.

[sagiegurari]

thanks!!! you raise a very valid point and I agree.

however, I'm thinking of another solution.
instead of linking to the watchexec which would increase compilation time to all users for a feature I assume most do not use and require me to implement some really cool logic you already have in cargo-watch, I'll simply use a specific cargo-watch version when installing.

I have a really good integration with cargo and rustup internally so setting a fixed version for cargo-watch would be easy and I'll also let users modify that via cargo-make external config file (their risk).
and once in a while, i'll upgrade that internal version after testing like I do every few months with rustc version for example.

[passcod]

Sounds good!

…

On Tue, 19 Feb 2019, 17:46 Sagie Gur-Ari ***@***.*** wrote: thanks!!! you raise a very valid point and I agree. however, I'm thinking of another solution. instead of linking to the watchexec which would increase compilation time to all users for a feature I assume most do not use and require me to implement some really cool logic you already have in cargo-watch, I'll simply use a specific cargo-watch version when installing. I have a really good integration with cargo and rustup internally so setting a fixed version for cargo-watch would be easy and I'll also let users modify that via cargo-make external config file (their risk). and once in a while, i'll upgrade that internal version after testing like I do every few months with rustc version for example. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#195 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJgi__w2q4EvMWuAbSSi8cBcBT7Vkftks5vO4GTgaJpZM4bBwr4> .

[sagiegurari]

implemented in 0.16.9 which will be released today.
thanks a lot for the suggestion!!!

[dakom]

I'm really liking cargo-make as a generic task runner, but that means I need to have it run tasks from outside a rust project... so I think I need to call watchexec which will then itself call cargo make [task]

That works fine, though there's about a 200-300ms overhead of calling cargo make itself. Would be cool if there was like a fast path for this use case, which I think is related to @passcod 's suggestion above?

[sagiegurari]

I'm not planning to embed it for the reasons already detailed above.
might mean 200ms but would reduce complications in the project like duplicating the logic found in cargo watch.