Include files from variable location

[pprkut]

I'm in a situation where I have multiple repos that pretty much all need the same justfiles and rather than duplicating the files and maintaining the duplicates I thought it would be great to have a central repository with the command definitions that get included in other projects.

Conceptually this already works great, the only problem is the location of the shared repository. I can either hardcode it to an absolute location on the filesystem (which doesn't work well with people working on the projects on different operating systems, and CI probably also doesn't like that very much) or use git submodules to include the shared repository in the project (which also comes with its own set of complications).

However, I think it would be really nice if just could resolve the to-be-included files from a variable location. There's different things that could work here, for example:

• Support some form of include path that you could define in an environment variable, where relative paths in include statements are resolved against all entries in the include path and the first matching one wins
• Support environment variables in include statements, so you could do something like !include $JUST_INCLUDES/module/common.justfile

I get the aim of the initial implementation to provide a simple solution for includes. I'm hoping neither of the two options would add too much complexity to the implementation 🙂

[tommyalatalo]

I would love to see this functionality implemented in a similar way to how Terraform references remote modules. Basically allow the user to enter a remote git repository URL and ref (branch, tag, commit) which would get fetched and used. This is a total game changer and would allow you to write independent justfiles in repos that reference centralized remote files as common "includes". The implications of this for use with CI systems are really quite amazing.

[peterhoeg]

How about using a git submodule (assuming you have your stuff in git of course)?

[casey]

I just merged #2055, which adds a new kind of shell-expanded string literal. They look like this x'$FOO' and can be used anywhere a string literal can be used, including module and import paths.

[laniakea64]

can be used anywhere a string literal can be used, including module and import paths.

@casey For me this syntax only works in settings, optional imports, [confirm(...)], and places where any string is valid. It does not work for me in mod statements or non-optional imports?

With this example justfile -

import x"$PWD/foo.just"

I get -

$ just --evaluate
error: Expected '*', ':', '$', '=', identifier, or '+', but found string
 ——▶ justfile:1:9
  │
1 │ import x"$PWD/foo.just"
  │         ^^^^^^^^^^^^^^^

Same error with either mod foo or mod? foo instead of import (and using just --unstable --evaluate).

[casey]

Whoops! I neglected to extend the parser to accept shell expanded string in mod and import paths. Just merged #2059 which fixes this.