Canop
add alias to job configuration
This allows you to write:
[jobs.example]
alias = ["ex", "exs"]
command = []
So you can do bacon example, bacon ex and bacon exs.
Is that really needed ?
This raises a question for users: when defining a job so as to replace another one, which is frequent, do you also automatically replace the aliases? Or do you have to specify the same set of aliases ?
If it's really needed is of course highly subjective, but for my use cases it would be a nice feature.
This raises a question for users: when defining a job so as to replace another one, which is frequent, do you also automatically replace the aliases? Or do you have to specify the same set of aliases ?
I would say that it should completely replace the existing aliases, that would also be the current implementation.
I wasn't clear.
Imagine there's a team specific job "check" with alias "c", and a key-binding c = "job:check". Some team member get used to bacon c.
Now, on a project of this team, a bacon.toml defines a new "check"job because it uses special features maybe. Most members of the team will probably be surprised that bacon check and bacon c no longer do the same thing, and that the c shortcut doesn't call anymore the same job than called with bacon c job.
The c shortcut not calling the new "check" job is not related to this PR, right?
If the new "check" job definition doesn't add the "c" alias, bacon check would work as intended and bacon c would throw an error that the job could not be found. I think this behavior makes sense.
Another option would be to merge all aliases from each previous job definition in the new job definition.
Yet another option would be to keep the previous job definitions and still allow their aliases to be called if they are not overwritten in the new definition.
IMHO I actually think adding aliases complicates the mental for me a bit of how bacon works and which job I would expect to actually be run. I don't personally have a need for aliases and it doesn't really affect me either way as I generally work with hotkeys and do not restart bacon to change job so I don't really have a horse in the race. That disclaimer added if I did need aliases I think I would create a job for each alias instead of defining them in the job I want aliased (Example below). I think that would make it more obvious what priority they have based on where they are defined. It is more typing so if it were something I used often I could see how I would want the syntactic sugar instead.
[jobs.example]
command = ["cargo", "run", "--example"]
need_stdout = true
allow_warnings = true
[jobs.ex]
command = ["echo", "alias used"]
on_success = "job:example"
[jobs.exs]
command = ["echo", "alias used"]
on_success = "job:example"
Having given this a bit more thought, I think with the use of global jobs. The extra typing might be a one time effort and adding diminishes the value of adding aliases in my opinion. @tversteeg do you normally have different aliases per project or are they just things you could add to prefs.toml?
If I did need aliases I think I would create a job for each alias instead of defining them in the job I want aliased (Example below). I think that would make it more obvious what priority they have based on where they are defined. It is more typing so if it were something I used often I could see how I would want the syntactic sugar instead.
[jobs.example] command = ["cargo", "run", "--example"] need_stdout = true allow_warnings = true [jobs.ex] command = ["echo", "alias used"] on_success = "job:example" [jobs.exs] command = ["echo", "alias used"] on_success = "job:example"
That's actually a good workaround that would also fulfill my current needs.
Do you normally have different aliases per project or are they just things you could add to prefs.toml?
I have different aliases per project, not globally.
@Canop should I close this PR?