I’m adding a task property that allows you to identify the task. With all this in mind, I’ve come up with minor revision to my idea that’s a little more explicit and unambiguous: - task: common
#Dotbot disallow code
It wouldn’t complicate the model at all for users who don’t need them, and the changes to the code would be minor. So, I wonder if that might be the source of discomfort and disconnect with these sorts of suggestions – the question of what tasks are actually meant to be and whether a mechanism for composition (rather than just a list of actions) is desirable…Īs I see it, yes, a mechanism for composition would be highly beneficial in a lot of cases, and tasks are very well suited to be that mechanism. There aren’t any tasks with multiple actions shown in the docs. The only reason I know they can is from looking at the code ( dispatcher.py:24). In fact, it’s not even clear to me if tasks are intended to compose multiple actions. But what’s not clear to me is if they’re thinking about it that way because they don’t know that tasks can already compose multiple actions, or if they need something more than that. What they’re talking about over there is a unit of composition that’s bigger than tasks. All it’s missing to be super useful is a name and a way of declaring in which situations it applies (and my suggestion was to reuse the existing if mechanism for that). It already can, itself, compose multiple actions.
what I’m proposing here is that I see the existing concept of a task as that unit of composition. The main difference between what’s been going there vs. And as I see it, composition is very much a declarative concept. It’s the ability to group some related actions and identity and describe them as a unit. To put a finer point on what I was trying to say in my previous comment: In both cases, I think it’s not control flow, but rather more powerful composition. I do think what folks are asking for there is closely related to what I’m asking for here. I think this small enhancement would make dotbot so much more flexible and powerful.Īfter I finished my PR and comment last night, I took a look at issue #81 based on the mention above, and that expanded my thinking a bit more and maybe helped me to see some of the disconnects. Plus, I could imagine this being useful with other directives – definitely for shell and create, and probably for many plugins, too. So, it would be wonderful if I didn’t have to repeat the same if option again and again and again.
#Dotbot disallow plus
pairs file for work, plus more…Since I can’t put two different entries for the same file under a single link task, I need to have different task for these cases, anyway. My use case is that I’d like to have a task with links that are always created, and then another set just for personal machines, and a third just for work machines. The idea is that you could define sets of links, or shell commands, or whatever task, for an environment/profile/whatever. If the executed command is not successful, the whole task would be skipped. I have an enhancement to propose: Allowing an if property (which would work just like the link option) on the top-level tasks, alongside each directive.
0 kommentar(er)
