Allow certain recipes to be expliciltly marked as runnable in children directories

[asdf8dfafjk]

I'll start with an example (actual text at end). One term I'm going to use is "owning directory" which is to say the directory which contains the .just file.

Say my recipe is git status

gs:
	git status

I however need to be in the directory with my .just file. (so called "Owning directory")

---

Now say I change it to

~~gs:
	git status

This means that git status can be run from any child directory in the repository. But it will still consider its working directory as the owning directory.

---

Now say I change it again to

~~gs:
	git status {~.}

This would still have working directory as owning directory but the command would be git status <relative path of current directory from owning directory>

---

Now say I change it again to

~~gs:
	git status {~/}

This would still have working directory as the owning directory but the command would be git status <absolute path of current directory>

---

Now say I change it again to

~~gs:
	git status {~~}

This would still have working directory as owning directory but the command would be git status <path of directory with .just file>

---

Now say I change it again to

~.gs:
	git status

The working directory of this recipe would be the current directory.

---

All these recipes would be invoked using plain j gs.

---

---

Proposal

Hello,

I want to propose a feature where you can allow a chosen subset of recipes to be callable from children. The purpose is to be able to run commands like git status (and ...?) from child directories without having to navigate to git root, or having multiple .just files scattered around.

There would be two components to this feature.

1. How to indicate that this recipe can be run by children?
2. How to indicate the working directory of a recipe?
3. How to pass values of "Owning directory" (by this I mean the directory containing the .just file), current directory relative to owning directory, and absolute path to current directory.

I propose the following:

1. Any recipe that starts with ~ is meant to be inheritable.
2. The working directory would be determined from the second character of a ~ beginning recipe. If the second character is ~ then working directory would be the owning directory. If the second character is . then the working directory would be the invocation directory.
3. 3 special variables would be autopopulated for such recipes. ~~, ~., ~/. They mean owning directory, invocation directory (relative to owning), invocation directory (absolute).

Implementation questiosn:

1. How do you go up and find out which of the parent directories has a .just file? What if the parent is a link? If so, what to do about the relative path?

2. When passing owning directory, should its absolute path be passed or relative, or both should have their individual symbols? (I ran out of symbols...)

[casey]

Thanks for the issue! I think these are good ideas.

I'm generally a bit hesitant to add new syntax, since it can be hard to read, and also a bit hard to plan, since different syntax elements can conflict with each other.

However, I think implementing some of these things with a generic annotation/attribute syntax, as proposed in #604, would be the way to go.

Some of what's proposed is invocation_directory() is the absolute path of the directory in which just was invoked, so it could be used instead of {~/}.

There isn't an equivalent for {~.}, but I'm wondering if it's necessary. Is there an instance where the absolute path can't be used?

justfile_directory() can be used instead of {~~}.

I'm not sure what ~~ means, since recipes can already be invoked from any subdirectory. Could you elaborate?

I think that ~.RECIPE_NAME, which sets the current working directory to the invocation directory, could be done with an annotation, something like:

#[no_cd]
foo:
  # recipe body

[asdf8dfafjk]

#[no_cd] is way cleaner than ~. I agree.

I'm not sure what ~~ means, ...

If put before the recipe name, it means that that recipe indeed can be called from a subdirectory, and the current working directory would be justfile_directory. Maybe a single ~ could be used but I wanted to be uniform ...

Thanks for the amazing tool btw, no more monthly fiddling with ~/.history in vim to remove all cd and ls and then backup.

[casey]

If put before the recipe name, it means that that recipe indeed can be called from a subdirectory, and the current working directory would be justfile_directory.

I'm not following, isn't that the default behavior? Currently, normal recipes can be called from any subdirectory, and the default directory is the one that contains the justfile.

Thanks for the amazing tool btw, no more monthly fiddling with ~/.history in vim to remove all cd and ls and then backup.

You bet! So glad to hear it's useful.

[asdf8dfafjk]

Wow, so yeah I just reread the manual and it looks like just does automatically look up for justfile. The problem lies somwhere in the fact that I have a custom invocation of just using an alias j and the fact that my justfile are named .just. Closing, thank you for your time :)

[casey]

Glad you fixed it! I like the idea of having an annotation to prevent a recipe for changing directories, so I created #762 to track that separately.

[asdf8dfafjk]

Created #1048, sorry for the noise

[asdf8dfafjk]

It is also important to note here that like global config which I recall that you've shown aversion to in the past for adding complication, inheritance as described above can potentially have the same effect and make things unclear in a multiuser environment. A counter argument to this would be the presence of --justfile= flag.