Pre-record hook


#1

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.


#2

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


#3

We could start with something like

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

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


#4

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();

#5

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.


#6

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


#7

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)