feature request: function to get repository root directory

[nemith]

With !include support now it has allowed me to start using just in a monorepo and having shared rules and macroish rules that can allow for reuse.

However including a common file is relative to the justfile that is being ran. So now when i start a new project I just have to be aware of the relative path to to the root of my repo and figure it out.

Example

build/common.just                   # common rules
project1/justfile                        # !include ../build/common.just
project2/subproject/justfile    # !include ../../build/common.just

This works for now but it would be nice to have this as just

!include {{repo_root()}} / "build/common.just"

I think this also means allowing evaluation in the include statement which may not be there.

A function also come in handy for docker commands and other things that may want to know about the root.

This could look for .git .hg` etc files, or could be a generic function to look up until a certain file/directory is found and return it or the base directory.

[jeffrey-aguilera]

If shell expansion were supported in the include directive, you could just do something like !include $(git rev-parse --show-cdup)build/common.just

[casey]

The !include directive is very primitive, and its argument is evaluated before parsing. This means that it doesn't have access to expressions or functions. I think that adding that functionality is beyond the scope of the current feature, since it would really be a mess.

The only thing that I could imagine doing would be adding ... as a shorthand for "the same directory as uppermost justfile".

So if you have:

justfile
common.just
foo/justfile
foo/bar/justfile

foo/justfile and foo/bar/justfile could both do !include .../common.just. Just would search for the uppermost justfile, and interpret common.just relative to the directory containing it.

[nemith]

foo/justfile and foo/bar/justfile could both do !include .../common.just. Just would search for the uppermost justfile, and interpret common.just relative to the directory containing it.

I think this would be perfect.

[nemith]

Thinking this through for an implementation a bit.

myrepo/
  |- justfile               # top level justfile
  |- build/
  |   |- common.just
  |- project1/justfile
  \- common/
      \- lib1/
          \- justfile

How far would the search work if !include .../common/common.just was added to both project1/justfile and common/lib/justfile?

Would you keep searching just the direct parent directories for a justfile or keep searching until / and then use the last justfile found? Would you stop at repo boundies (i.e looking for a .git, .hg`, etc folder?)

If it just searches parents that means i would need an empty justfile at common/ just to allow searching for higher levels?

A counter proposal would be to allow for some special file that would be searched for to find the root (.justroot) or even add some repo wide configurations (.justconfig) which could have global settings like setting unstable = true for everything in the repo without needing a wrapper command.

[casey]

How far would the search work if !include .../common/common.just was added to both project1/justfile and common/lib/justfile?

Would you keep searching just the direct parent directories for a justfile or keep searching until / and then use the last justfile found? Would you stop at repo boundies (i.e looking for a .git, .hg`, etc folder?)

I'm thinking that you would search parent directories up to / and use the last justfile found. Stopping at repo boundaries could be a later feature, our you could just add a set root := true setting to make it stop looking. This would be backwards compatible, so it's best to punt on it for the initial PR, to get something working in.

If it just searches parents that means i would need an empty justfile at common/ just to allow searching for higher levels?

I don't think you would need to do this. Just would keep going up if it saw a directory with no justfile.

A counter proposal would be to allow for some special file that would be searched for to find the root (.justroot) or even add some repo wide configurations (.justconfig) which could have global settings like setting unstable = true for everything in the repo without needing a wrapper command.

I like the idea of !include .../foo because it's opt-in on a very fine-grained basis. If you never use ..., nothing changes, it's only if you use ... that you get this new behavior, and later we can add tweaks that change exactly what that behavior is.

Whenever I'm thinking about a new feature, I'm thinking:

• What is the minimal thing we can add?
• Can we add something simple that can be improved later in a backwards compatible way?

[pprkut]

I think this is related to #1580. Perhaps #1849 is an alternative solution that works here too? You could add all the parent directories as entries in the environment variable and just would try to import in order of preference. Maybe not as nice as ..., but it should do the trick.