I am definitely interested in seeing modules fleshed out a bit more. I'm coming from being a fairly heavy make user where our team could organize make 'stubs' and include them on a per-repo basis.

Something like this was nice and handy in Make-land, and is definitely nearly there with Just

Makefile

-include .env
-include make.d/*.make

make.d/docker.make

docker/build:
   docker build ...

docker/login:
   docker login ....

The recipe naming with the / gave us faux-namespacing, which worked fairly well, but is arguably better implemented with Just modules. The one thing that keeps me from using them in this Make style way, is that variables from main/root Justfile don't cascade into the sub-modules

This has made it difficult to fully embrace modules, so we resort to using imports in Just and doing a more 'restrictive' faux-namespacing in the recipe names.

I would therefore 1 all the following, as I think they all contribute

• Recipes defined in one module can be depended on from another
• Variables defined in one module can be referenced from another
• Allow creating inline modules that are declared and defined in a single module
• Add a setting which allows a parent module to propagate settings to submodules
• Consider adding a reverse setting, which allows a child module to inherit settings from its parent

As an aside, I think I'd be perfect happy as well if recipe names could include some special characters that allow the 'faux' namespacing I mention, / is ideal ( or even \, but even a . would suffice. Then I could just use imports

Adding this one to the list: #2271

We have nested just mods that goes:

./Justfile
./iac/mod.just
./iac/docker/mod.just
./iac/docker/stack/mod.just

Which allows us to call just iac docker stack deploy

However from ./iac/docker/stack/mod.just I want to call a task defined in ./iac/docker/stack/mod.just and not have to use the fully qualified just iac docker stack <local-task> because this module is used in multiple projects with different file hierarchies.

How exactly could I call a local task, without using the hierarchy?

To highlight the issue in a different way:

I have a parent git repo, which has git submodules. Each submodule I wish to have a Justfile that works independently for those development teams. However I wish to expose that submodule tasks to the parent monorepo without modifications to the submodule Justfile. This is not possible because as soon as I include it as a module I now have to call the fully qualified module path

Eg When running submodule/Justfile in isolation I can call just package without issue

build:
  # do stuff
  
package:
  just build

But when I include it in a monorepo, and try to expose its tasks to a parent Justfile just build must be modified to just submodule build

./monorepo/Justfile

mod submodule

./monorepo/submodule/Justfile

build:
  # do stuff
  
package:
  just build # <---- this now breaks, and has to be aware of its position in the module hierarchy

I have put some thought into this. Should calls to just defined in a nested module not default to recipes in the current file, and then navigate up until it finds a recipe that matches? Why does a submodule need to be aware of its location in the module hierarchy?

And similarly you can should be able to call a dependancy to a module, relative to the currently module hierarchy. ie

Given

./Justfile
./iac/mod.just
./iac/docker/mod.just
./iac/docker/stack/mod.just

In ./iac/docker/mod.just you should be able to create a dep to its modules, without having any need to know where its being included in the parent hierarchy.

deploy env="dev": (stack/deploy env)

# or 

deploy env="dev":
  just stack deploy {{env}}
  
# not

deploy env="dev":
  just iac docker stack deploy {{env}}

Not, as "docker/mod.just" would now have to know that it resides in iac, and can be installed anywhere else but in that exact hierarchy.