Skip to content
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

Running recipes from parent directories when there's no recipe with the same name in the current directory #1036

Closed
soenkehahn opened this issue Nov 26, 2021 · 9 comments · Fixed by #1149

Comments

@soenkehahn
Copy link
Contributor

soenkehahn commented Nov 26, 2021

When my current directory does not contain a justfile but a parent directory does, just looks for recipes in the justfile in that parent dir. This allows me to e.g. place a justfile in the root of a monorepo and have its recipes available everywhere.

However, this does not work when my current directory contains a justfile, even if that justfile does not contain the recipe I want to run. Here's an example:

$ cat justfile
global-recipe:
  echo global-recipe
$ cd subdir/
$ cat justfile
local-recipe:
  echo local-recipe
$ just local-recipe
echo local-recipe
local-recipe
$ just global-recipe
error: Justfile does not contain recipe `global-recipe`.
Did you mean `local-recipe`?
$

I would've expected this to work, as long as my local justfile doesn't shadow the recipe that's higher up. Is there a good reason why this shouldn't work?

@casey
Copy link
Owner

casey commented Nov 26, 2021

My initial reaction is that a module system is the way to support this. See #383 and #929.

I can imagine an implementation that would use the first recipe to inform how just searches for the justfile, but I'm not sure if that would favorably compare to a module system.

A module system is a huge new feature, but maybe it could be scoped down to the point where the initial implementation isn't too bad, and it supports this use-case. There's also the --unstable flag, which can be used to add incomplete features that can change in backwards incompatible ways. We could also have an unstable setting, i.e. set unstable that could do this without needing to pass a flag.

@asdf8dfafjk
Copy link
Contributor

Since you consider module system to be huge, and since a rudimentary form of inheritance works right now, I wonder if #761 (pardon the possibly rude repetition) might fit? I'd be happy to tackle the actual work btw.

@casey
Copy link
Owner

casey commented Dec 24, 2021

I think the first version of the module system could be really simple. Start in the current directory, and as you go up to the justfile, every time you see a file called "mod.just", add that to a list. Then, when you get to the justfile, parse the justfile, and all the modules in the list.

Then, start looking in the justfiles one by one, starting with the deepest going upwards. When you find a justfile with the recipe, use that justfile.

@asdf8dfafjk
Copy link
Contributor

Yeah, that's actually pretty easy to mentally model.

@casey
Copy link
Owner

casey commented Mar 24, 2022

There are some tricky things to consider here. One example is, if the recipe isn't in the current justfile, and you search up for another justfile, and you find another justfile but there's a parse error, do you display that error? I started implementing this, but hit some of these tricky things and stopped working on it. I think now I should have just finished it, and put it behind the --unstable flag, and addressed the tricky bits later.

@soenkehahn
Copy link
Contributor Author

[...] do you display that error?

I do agree that this is a bit tricky, but I would assume that yes, you just display that error.

I guess another question is whether just --list shows recipes from justfiles in parent directories or not. I would've assumed that it doesn't, but it's weird that you can execute a recipe that isn't in that list.

@eelkevdbos
Copy link

eelkevdbos commented Mar 26, 2022

There are some tricky things to consider here. One example is, if the recipe isn't in the current justfile, and you search up for another justfile, and you find another justfile but there's a parse error, do you display that error? I started implementing this, but hit some of these tricky things and stopped working on it. I think now I should have just finished it, and put it behind the --unstable flag, and addressed the tricky bits later.

First of all, this would be a killer feature @casey @soenkehahn. Some of the solutions that come to mind:

  • Have some stack tracing available on a parse error that highlights which file is currently being parsed, this could be a nice addition as well to the error 'No justfiles found' to see which paths are walked
  • Add an option --verbose/--debug that allows for more verbosity, printing the actual parsing steps as debug logs to stdout
  • Add an option --no-modules to disable module loading behavior, and provide the use of this option in the stack trace mentioned above to help people debug their problem.
  • Add an option to specifically include modules --module "ops" --module "docker", this could also be useful in context of the remote modules talked about in the other issues --module "https://github.com/org/repo/tree/main/docker.just"

Other things that come to mind:

  • Being very explicit in the most specific .justfile that expansion is allowed / disallowed. This could even be used to limit expansion to arbitrary levels: set allowed_modules = '../' or set allowed_modules = ['~/', '../', 'https://github.com/org/repo/tree/main/docker.just']

@casey
Copy link
Owner

casey commented Mar 31, 2022

I implemented a simple version of this feature in #1149 and released a new version of just, 1.1.2, which contains it. Try it out and let me know what you think!

The feature is currently behind the --unstable flag, so I created #1148 to track feedback prior to stabilization.

@asdf8dfafjk
Copy link
Contributor

Thanks so much. I was on a road trip of sorts for the first half of the year so couldn't chime in, but the one man army that you are, clearly that didn't matter :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants