Pre-record hook

Hi everyone. I start using pijul again and I was thinking that a cool feature would be to be able to specify a bunch of script to run when recording; the idea is the record would fail in case one of the scripts does not return 0.

Would you like to see something like that added to pijul? I think it is fairly easy to add, by extending .pijul/meta.toml.

1 Like

I’d love to have that, maybe in the form of a command / list of commands passed to the current shell?

We could start with something like

pre = [ "cmd", "args1", "args2",
        "make", "rule"

And we could work on that latter to give a more user friendly way to configure it.

Another way to get the same result (vector of vectors of commands + arguments) from a string, in a user-friendly way, would be:

let commands:Vec<Vec<_>> = s.split(';').map(|cmd| cmd.split(' ').collect()).collect();

I’ve pushed a first patch which implements a very basic support for hooks.

Edit: Okay so I have created a discussion on the nest with two patches attached. As a side note, there is an issue with the UI to attach a patch. By default, after selecting the correct patch, nothing happens when clicking on submit (except the selection is lost). However, I have noticed that the source repository is by default ogma, which is the last I have created. Once I select pijul, I was able to attached my patch (but the UI was confusing: the selector has been reset to ogma, but pijul appeared right after it).

(@laumann, you may want to try on your discussion about the conflicts to verify you have the same behaviour)

It is not very clear, but I hope it can help anyway.

Edit again: okay, pushed a new patch, it’s on the nest discussion.

Thanks! I’d like to wait for the current conflict with Cargo.lock to be resolved, before trying this out.

It makes sense, yes. If there is an issue in the patch dependencies computation, we should try not to mess with the dependency graph any further.

Before applying the patch, I want to do the following:

  • Add “patch name” hooks (to check if a patch name is well-formed thanks to a script)
  • Add some documentation (man pages would be great)