-
Notifications
You must be signed in to change notification settings - Fork 450
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
Allow dependencies that take parameters #289
Comments
Is there a good default value you could give to
You could then override it on the command line like so:
|
I'm afraid I can't, that's the whole problem, I thought about using the default value but I want to make sure that this particular value is always passed by user |
Hmm, darn, this is a tricky one. The only solution I can think of is one which would be pretty weird. Basically to allow dependencies that take the exact same number of arguments, and pass the arguments of the dependee through, which would allow: run stuff:
cd {{stuff}} && python main.py
visualize stuff:
python src/visualize.py {{stuff}}
run_visualize stuff: run visualize This would be preeeeetty magical though. An additional constraint could be that they must have the same name, which would mean that the above would still work, but the following wouldn't: run bar:
cd {{bar}} && python main.py
visualize foo:
python src/visualize.py {{foo}}
run_visualize stuff: run visualize Since I can't decide whether this is super weird or not. What do you think? Also, anyone else, would you use this or has this been an issue before? |
I'm not really sure this is a good idea, because that would break backward compatibility, consider
what if
What do you think? |
When I think about it now, maybe it's a better idea to introduce something like that within the body of the recipe? I'd think that a lot of the times you want to run the recipes somewhere in the middle of different operations like so:
That way you don't need to change the dependencies syntax, and if user wants dependencies to take arguments then he'd need to call them by hand from within the body of the recipe. But now there should be a standardized way to mark a line in the body that it starts a recipe, maybe similar to how |
If Going the sigil route, I think it would be better to have a sigil that meant the opposite, that this line wasn't a normal recipe line, and was a call to a dependency or set a variable. Still not sure about either route, since recursively calling just is a viable solution. |
Oh I meant the sygil to be working in the way you described it - something to describe a non-normal line of recipe |
Thinking about this a bit; I think that introducing special lines within recipes would be a big step*, so the solution I like right now is your version of parameter passing, using parenthesis for grouping: foo arg1 arg2: (bar arg1 arg2) (baz arg2) I'm not sure when I'll be able to get to it though, I'm working on a parser-generator, which is taking all my attention at the moment. * Never say never though! This would also allow intra-recipe assignments, which have been requested before. |
I started to implement this, but I ran into an issue. Check out the following: foo a: (baz a)
bar a: (baz a)
baz a:
echo {{a}}
bob a b: (foo a) (bar b) If we run |
Is this bad? It looks like that's exactly what should happen... |
I'm not sure if it should be allowed. Up until now, any recipe would only ever run once in any particular run. There are two options here, either treat those two instances of My initial reaction was that I should disallow it, mostly because that's my usual strategy when extending However, it might be reasonable to treat them as separate recipe invocations, but only run them once if the arguments match. Can you think of a case where this would be useful? I'll try to come up with one tomorrow, but it's bedtime 😪 |
I also ran into this issue-- one other consideration for this is how variadic parameters are sent to dependencies as well. My vote: |
I have just run into a similar issue where a dependency requires the argument. I think @fuine's suggestion of having a way of running recipes from within other recipes would be a suitable alternative. In my case I need something like
The current restriction on dependencies not having arguments could stay as it is which would prevent recipes being run twice with different arguments (unless explicitly called). Could maybe introduce a new syntax to prevent recipes overriding existing commands. Something like
|
@tpoliaw One possibility to work around this would be to invoke just recursively, i.e.: build target:
# do stuff
just prepare {{target}}_output
# continue doing stuff It feels a little unsatisfying, but it should work. I'd like to keep just shell agnostic, so I'm hesitant to add syntax which might conflict with commands in non-bash shell languages. One way to do it, although it's very weird looking, would be to put the marker for an intra-recipe invocation somewhere in the leading whitespace for the line, like so: build target:
# do stuff
: prepare {{target}}_output
# continue doing stuff Since a We'd have to figure how/if these intra recipe calls would participate in dependency resolution. I.e. are transitive dependencies of intra-recipe invocations re-run every time they're invoked? |
That's what I've been doing so far but it falls over if the justfile is not in the current directory tree. eg running I like the idea of an opening |
@tpoliaw, ahh, gotcha that's unfortunate. It's not so much that |
I've started working on this feature in #555. I have a couple of open questions around syntax and symantics, so do check the draft PR out and and let me know how you feel either way! |
This has been implemented and included in v0.5.2, which I just published to crates.io. Releases should be available soon here. (@clarfon I opened #558 to track expanding dependencies w/variadic arguments, which I quite like, although it'll be tricky to implement.) And thank you for your patience with this now two-year old feature request :) |
I'm not sure if this is possible, but consider the following case:
Is there a way to create
run_visualize
recipe without subsequent executions ofjust
from the mainjust
process?The text was updated successfully, but these errors were encountered: