-
Notifications
You must be signed in to change notification settings - Fork 466
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
Fallback justfile stabilization tracking issue #1148
Comments
Hey! I just started exploring that feature and it's great, thanks for adding it! Are you planning to include also fallback of variables between parent/child justfiles? In the current setup, I have some 'global variables' defined in the main justfile that I am using in a command. Now, if I want to overwrite that command via child justfile, I also need to redefine all of the variables, there is no fallback for them. I guess that might not be exactly what this issue is about. Probably a better implementation would not be rather an explicit import to force just to get all settings and vars from the parent. |
You bet, glad you like it!
I don't think so. This feature is a simple stopgap to make it easier to work with multi-justfile repositories. For something where recipes and variables from multiple justfiles in the same invocation, have a look at #929. There's no active work on that at the moment, but some day! |
I wanted this and then discovered that it was already available! I'm planning to use it to have a justfile in ~ with general shell shortcuts. The question I have about the current implementation is about tab completion. This seems like it would become even more important with an increased number of recipes. Presently, it looks like tab completion only works with recipes in the first justfile found. I wonder what the right solution is:
I can't decide if 2 would be too much. Possibly it could get confusing, since two different files could contain multiple receipes with the same name. The issue with 3 is that the tab completions could appear to change as you changed the initial string. I'm not really loving the first behavior, though. Now that I've turned on tab completion, I find myself relying on it for nearly every invocation. If I can't use it for the upper-level justfiles, that would make me less likely to use them. |
I think But I think that ultimately if submodules become a reality that at the very least completions should take submodules into consideration. |
Interesting situation brought up in the Discord channel while might affect this feature:
build:
just build-{{ os_family() }}
build-unix:
# unix build command goes here
build-windows:
# windows build command goes here When this feature is implemented, that call to I think a solution to this would be to make calls to |
I think it would be best that if there are conflicts Just exists with an error explaining the shadowing issue. Then the user would be aware of the issue and could fix it as they see fit. Maybe Just could provide suggestions for common situations as time goes on as well. |
Hello Everyone, i just started looking into just because we want it to replace a custom build tool. |
This has been unstable for a while, and no complaints so far. @52f73db mentioned that he was using it in #1148, and it seems like it might be time to stabilize it. One concern I have is that this is a change in behavior. If a user is relying on getting an error in a sub-justfile, they might be surprised when the recipe runs in the parent. |
Could make it a setting to enable it. We're adopting Just now and using this feature as fundamental. Had to create an alias just so everyone doesn't have to add |
Great idea! I think that's better than stabilizing it as-is, since falling back to parent justfiles could be undesirable if you aren't expecting it. Also, if you plan on using fallback, you can omit the setting in the root justfile in your repository, and I implemented it in this PR, have a look: #1368 This would make things worse for your use-case temporarily, since you would have to add
How does that sound? |
Forgot to @ @rberger |
That's awesome idea in my opinion. We have a structure of monorepo where we have per-project justfile as well as a main, repository wide justfile and falling back even further up than the monorepo root is not desirable. Having it as a setting in each justfile solves that issue completely. The stabilization path, although more annoying at start, is a thing that we just need to live with. |
@soenkehahn What do you think of this? You would have to put |
Nobody complained, so I just released version 1.6.0, which has the new setting-controlled fallback behavior. It's still unstable, and barring any issues, I'll make it unstable in the next release in a month or so. Binaries should be available soon on the release page. Try it out and let me know what you think! |
Hey! Thanks for implementing that! One problem I stumbled on while implementing the switch.
The reason is obvious, I forgot to upgrade version of just on my machine. This leads to some complications however, I need to force everyone to upgrade their versions basically before I merge that commit. Otherwise, I will break workflow for literally everyone as well as for CI. The latter is obviously easier to deal with. Is throwing an error an optimal solution for dealing with unknown settings in face of a super stability of just? It means that adoption of backward incompatible changes in justfiles is going to be very hard. Wouldn't a warning and ignoring of Edit: |
That's definitely annoying! However I don't think In this case though, there is something that could be done to make this transaction less painful:
This would allow you to wait for the everyone to update to the new version where However, this would be at the expense of having to wait a longer time for the feature to be stabilized, since I wouldn't want to stabilize it at the same time that the default changes. How hard is it to ensure that everyone has upgraded to the new version of As you said, this is an unstable feature, so breaking changes are to be expected. However, there's no reason not to try to minimize how annoying they are. |
I think it won't be that hard to ensure everyone to use just. The only prerequisite is to be sure that the new version is available via brew so people have a familiar way of obtaining it. I think your proposed solution will work, definitely it will ease the transition. It would be great if you could walk this release path. And regarding ignoring unknown settings - how about introducing a switch that would allow for unknown settings to be present in a justfile? Kind of a double edged sword but could help with making transition smoother. |
Done! I just released 1.7.0, which changes the new Check the updated timeline above, and let me know if it's too fast or too slow. |
Oh wow, that was fast! I think a month for each phase is plenty of time. Thank you! |
I just released 1.9.0, which changes the |
@casey did this stabilize in to 1.10.0 by any chance? Just gave it a shot and I think it still has 1.9.0 behavior. |
@nyonson Nope, I didn't wasn't able to get it in, but |
It is done! I just published 1.11.0, with fallback stabilized. Prebuilt binaries should be up on the releases page soon. Thanks for waiting and providing feedback! |
This is a tracking issue for stabilizing the currently unstable feature which allows
just
to check justfiles in parent directories if a recipe is missing from the first justfile it finds.The feature is currently unstable. Please comment with any feedback, suggestions, or if you like the feature and think it's ready for stabilization.
Update 2022-10-19
Looks like this is getting stabilized, with a change to behavior. The change is that fallback through a justfile in which a recipe is not found will only occur if the justfile contains
set fallback
orset fallback := true
.Stabilization timeline:
Please try out the new setting-based fallback in just 1.6.0 and let me know if you have any issues. Also, regardless of issues, let me know if it works or doesn't work for your use case.
The text was updated successfully, but these errors were encountered: