-
Notifications
You must be signed in to change notification settings - Fork 481
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
Using multiple justfiles / default include user-just file #1025
Comments
Thank you for the kind words! Thank you for using I think this probably depends on adding some kind of module system, which is tracked in #383. You'd want to have a module system, import the user-level justfile in your justfile, and then call recipes from the user-level justfile. |
I understand. That ticket probably makes more sense in the long run. Since I admittedly only skimmed #383, please let me know if the following is addressed there already and I have to give the ticket a more detailed read: Would allowing multiple If this is not an acceptable idea for reasons that I overlooked, please feel free to close this ticket in favor of #383. |
FWIW, the need for this feature is reduced by the existence of this: https://just.systems/man/en/chapter_51.html#invoking-justfiles-in-other-directories |
It would be very useful if just had support for local files, similar to how mise does it. For inspiration, see the mise docs regarding support for various filenames. It is common to have some personal just commands in a specific project, that are not suitable for sharing with others. This is different from having a module system. And it is different from invoking user just files And it is different from invoking justfiles in other directories. The goal of having a local file is to be able to extend the project |
You should be able to do:
If |
Wow this is a great solve, thanks @casey I won't say this is a shortcoming, but more a feature request. I'd like a handful of So I guess my request: a machine-level config that would automatically apply for all directories (or all sub directories). Or I'd be happy for a workaround! Maybe a zsh auto-apply? I'm just not familiar enough with the cool stuff just can do. Either way, thanks for the reply and big fan of the repo! |
@kvenn Does the --global-justfile option help? This allows you to call recipes from a global justfile. You do need to supply a flag, I don't know if an auto-import mechanism would be useful. I think it might be pretty confusing, since you would get conflicts if recipes in the auto-import had the same name as those in the justfile, and justfiles which depended on recipes in the auto import wouldn't work if the setting wasn't set, and it would be pretty mysterious what was going wrong. |
You're a legend! I was on just 1.22 so didn't even know about this. I created an alias and it's working like a dream. # Alias to call global recipes in ~/.config/just/justfile
alias jg="just --global-justfile" Do you know if there's any way to get the global recipes to show up in the shell completion? |
Dope, glad that works for you! I don't know how to get global recipes to show up in shell completions, unfortunately. Recipe completion is pretty hacked together. |
Hi,
I was thinking of the following use case: Let's consider I have project specific
justfiles
that invoke the right build / test commands for the project in the directory in which they are placed. But there are a few cross-project commands that are useful to have in every project, e.g., applying clang-format. These won't change between different projects.Instead of copying them into every justfile, I'd much rather put them in a user-level justfile. From the
README.adoc
I thought I could just place them in the~/.user.justfile
and have them available next to all other recipes from the local justfile. This is not the case as far as I can tell from experimentation. Next I tried supplying multiple-f
parameters. This is also not allowed.I understand that including multiple justfiles makes conflict resolution of recipe names necessary. It also invites other corner cases and might be overall undesirable. I tried searching for past discussions on the issue tracker but was not very lucky to find relevant ones.
Therefore, I decided to create this issue to get an understanding of what is already possible and what can be considered future improvements, for which you are willing to accept PRs.
Thank you so much for such a well-maintained project. :)
The text was updated successfully, but these errors were encountered: