Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stashed tasks functionality #558

Closed
Squirreljetpack opened this issue Jul 26, 2024 · 9 comments · Fixed by #561
Closed

Stashed tasks functionality #558

Squirreljetpack opened this issue Jul 26, 2024 · 9 comments · Fixed by #561

Comments

@Squirreljetpack
Copy link

Squirreljetpack commented Jul 26, 2024

A detailed description of the feature you would like to see added.

Not sure if undocumented, but I couldn't find any options for handling stashed tasks in the cli.
Like maybe you want to enqueue a task without removing it from stashed
Or you want to remove all stashed tasks

Explain your usecase of the requested feature

This came up because I didn't find any better way to remove all stashed tasks without starting them than by parsing for their id's. Since kill only kills running tasks?

Alternatives

No response

Additional context

If this fits the project's scope, I'd be interested in submitting a pull request.

@Nukesor
Copy link
Owner

Nukesor commented Jul 26, 2024

So. There's the remove command for removing tasks without starting them.

How exactly would "enqueue a task without removing from stash" look like? Enqueueing means to put it inside of the queue. Why should it stay stashed?

@Squirreljetpack
Copy link
Author

Squirreljetpack commented Jul 27, 2024

well for common pueue commands, you could stash them,
and activate them from there.
But actually I have a fzf script from this that just reads from a file.
So maybe it's not such a good idea to use stashed tasks for this purpose.
Though since pueue stash and pueue enqueue are seperate commands, it seems a bit more intuitive that you may be able to do more with stashed tasks than just start/enqueue them?

But on the first point:
Though I guess you can remove stashed commands by modifying the fzf script in the docs to have a remove task keybind.
But I thought it was a bit strange that there is no group-level remove.
As there is group-level reset and clean.

@Nukesor
Copy link
Owner

Nukesor commented Jul 27, 2024

What do you mean with "common pueue commands"? Could you explain your usecase in a bit more detail?
And what fzf script are you talking about and what is it reading from a file?

If you're talking about the fzf scripts in the wiki, those aren't part of the official project and rather snippets provided by the community.

Regarding the first point:
How would a pueue remove -g group_name differ from a pueue reset -g group_name?

@Squirreljetpack
Copy link
Author

Squirreljetpack commented Jul 27, 2024

I use this script to help me select. The input method is kinda scuffed but its convenient.
Some commands I run are to use pueue to run rclone or set alarm
pueue remove -g would not kill tasks, just remove stashed ones. That is those not considered for execution.

#!/bin/zsh

FILENAME=$ZSHDIR/ancillary/pujobs
INPUT="$1"

# useful for adding a recurring task
# Specifying the command via arg adds it to ps group

if [[ "$INPUT" == "-e" ]]; then
    echo "Enter the command to add and execute:"
    read -r NEW_COMMAND
    echo "$NEW_COMMAND" >>"$FILENAME"
    OUTPUT=$(pueue add --print-task-id -- "$NEW_COMMAND")
elif [[ "$INPUT" =~ ^[0-9]+$ ]]; then
    LINE_CONTENT=$(sed "${INPUT}q;d" "$FILENAME")
    if [[ -z $LINE_CONTENT ]]; then
        exit 1
    fi
    OUTPUT=$(pueue add -g ps "$LINE_CONTENT")
elif [[ -n "$INPUT" ]]; then # input with single quotes
    OUTPUT=$(pueue add -g ps --print-task-id -- "$INPUT")
else
    LINE_CONTENT=$(cat $FILENAME | fzf --header "$FILENAME" --bind "ctrl-o:become($EDITOR $FILENAME)")
    if [[ -z $LINE_CONTENT ]]; then exit 1; fi
    OUTPUT=$(pueue add --print-task-id -- "$LINE_CONTENT")
fi

# TASK_ID=$(echo "$OUTPUT" | $GREP_COMMAND -oP '(?<=id )\d+')

echo "$OUTPUT"

edit: one reason not to pop a queued job from stash is that could open the way for pu to run repeated scheduled jobs like cron maybe? - okay i saw this is not in scope in another issue, it's good to know that pueue could theoretically be made to serve this purpose, it's so much nicer than using cron/systemd in many ways relevant to my use case already. (user tasks which can be failable)

After some thought, if u have the time, my lingering question is really about why have stashed and queue be different commands, why not stash+queue in one go rather than having to do one extra, admittedly easy step with the ID's?

@Nukesor
Copy link
Owner

Nukesor commented Jul 28, 2024

I'm still very much confused.
What do you mean by "stash+queue in one go"
And what do you mean by "stashed and queue be different commands"? There's only the stash command.

When you do a pueue add "some command", the task is immediately queued unless it's called with the --stashed flag, which stashes the task away for sometime later.

Tasks only ever get stashed when the user explicitly decides to do so, which can also be done at any time via the pueue stash command, which takes a queued task and stashes it away.

Stashed tasks can then be enqueued via the pueue enqueue command, which puts them into the Queued state where they'll be processed as usual.

I feel like you're confusing pueue stash with the behavior of git stash, which behaves like a stack of changes. However, even in git, you can apply stashed entries from anywhere inside of that stack. The stack is just a convenience layer on top of the set of changesets, to make it more convenient to use.
In pueue, there's no stack. Stashed is a state that is part of the Pueue's state machine for tasks.

@Nukesor
Copy link
Owner

Nukesor commented Jul 28, 2024

I made a simplistic diagram of the states and their transitions for you to better visualize how this works:

Pueue State Diagram

@Squirreljetpack
Copy link
Author

Squirreljetpack commented Jul 28, 2024

Thx for the diagram, I was a little curious about which states there were.
Do you have an example of when stashing a task might be useful?
I can only think of maybe you use pueue to a batch of some long run processes like media conversion, and u change ur mind/want to manually save some tasks for later. (Add then stash)
Or in my case, have a notification script, and stash + queue that script to act as an alarm. (Add as stashed)
I feel like that case is the more common usage of pueue add --stashed (not sure if correct), and in that case, it makes a lot of sense to have pueue add --enqueue "datestring" -- 'command'.
In the first case, you may want to unstash or cancel those tasks in batch.
So it could be a small change but possibly sensible change to have batch enqueue/remove for stashed tasks?

@Nukesor
Copy link
Owner

Nukesor commented Jul 28, 2024

Correct. Stashing is mostly for when you add a task and notice that now is not the time to run it.
Or when you have a command that you want to run at some point, but not right now.

Your proposed usecase is already implemented with the --delay flag on pueue add.
However, it actually is missing on the pueue stash command, which seems like a reasonable addition.

A --group flag for enqueue also seems reasonable, as it mirrors the behavior of most other commands.

For remove i'm not too much of a fan to be honest as there're multiple problems when designing that interface.

  • Two new flags would need to be added --group and --stashed
  • --group on its own wouldn't work in most usecases as the remove command cannot remove running/paused commands
  • --stashed on its own wouldn't work, as it's unclear what's selected.
  • You would need to combine --stashed with --group and --stashed.

That just isn't a good ui design.

Also, I haven't heard of somebody actually adding loads of stashed tasks and removing them.
I would like to hear a real world usecase, which I always require before considering to add new features that appear like edge-cases.

@Squirreljetpack
Copy link
Author

  1. Oh ty, somehow missed that flag ha.
  2. Yeah okay I agree. I think without the fzf script on the wiki it could maybe be a bit annoying to manage the tasks if for some reason someone (ha) stashed them without enqueuing them and later wanted to get rid of them, but with it the extra functionality is completely superfluous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants