casey
Allow setting duplicate settings
I've got two justfiles across related projects. Each should work on their own, but the child imports the parent for extra (optional) functionality. It's roughly:
# ~/parent/justfile
base:
echo "in base!"
# ~/child/justfile
import? '../parent/justfile'
child:
echo "in child!"
And it works great!
But, I want to set quiet in both files. If I always used child when parent was present, then I could just piggyback on a definition in parent. Or, exclude it from parent and set it in each child. But, since each justfile should work independently, I find myself wanting to set it in both places. Today, I get an error:
Setting `quiet` first set on line 1 is redefined on line 4
I'd expect it to follow the existing allow-duplicate-variables behavior: last setting wins.
Is this sort of thing possible today? Alternatively, would you be open to a PR?
Settings and variables are distinct, so allow-duplicate-variables doesn't help with settings.
I'm a bit hesitant to add more allow-duplicate-* settings.
They're really a hack to, originally, work around the lack of modules, and now to work around limitations of modules. Modules have their own settings scope, so you can put whatever settings you want inside of submodules and they won't conflict. The biggest limitation is that you can't call recipes in child modules, which is, I think, the main reason why often using imports won't help with particular use cases.
Right, in our case we're using these across repos (only some of which are public). The example parent/justfile is a close-source repo while (the 7 different) children justfiles are in open source repos. The children files should work on their own, but employees working on those repos have access to additional internal recipes defined in the parent (that can be called from the child directories).
Quiet isn't a big deal (and we can prefix @ on every parent recipe), but a better solution would be useful. Doesn't need to be an allow-duplicate-settings specifically though. Anything that would let us do "set this setting if not set" would be really useful. Maybe something like set? quiet or set quiet ?= true?
set? quiet isn't great, because it introduces order dependence, which is something that just tries to avoid. When not using allow-duplicate settings or recipes, the order of everything in a justfile doesn't matter, which is a simpler mental model.
What if there's no syntax changes, it's only an error to set a setting to a new value, but a no-op to set it to the same value again?
So multiple files can all have the same setting, but disagreements would error out (same as today).
That's definitely less bad. I vaguely worry that it would mask user error, but I think it would be okay, and probably what most people need. I want to let this feature request sit for a little bit, and collect some feedback and see if anyone else needs it.
I'm new to using just, but have run into this issue in one of my use-cases. Very similar to the originally discussed issue, but I'm hitting allow-duplicate-recipes as the offending setting across a tree of imports (several optional), and if I could set it at the top level justfile of each branch that would simplify the portability of this setup greatly.
What if there's no syntax changes, it's only an error to set a setting to a new value, but a no-op to set it to the same value again?
So multiple files can all have the same setting, but disagreements would error out (same as today).
This might be a very niche use, and I might not be seeing the whole picture, but this fix would work great for me.
In my opinion, set allow-duplicate-variables and set allow-duplicate-recipes when used in a justfile you import, shouldn't affect the justfile importing this file. Wouldn't there be a way to make those apply only in the local justfile but not to justfile importing your justfile? It is not because I decide to override symbols that I want downstream users to be able to silently do that as well...
