Open gl-yziquel opened 2 months ago
This can more or less already be achieved with optional imports, but, still, it would nice.
I'm not sure what the use-case is here. Can you provide a concrete use case, with example justfiles?
Having the same kind of release process as rust does. Hiding features behind gates so that you do not need to manage both a master
and a develop
branch in git when developing executable Justfiles that behave just like CLIs.
I've been hacking together an executable justfile that processes rustdoc json through rustdoc, jq, jo, tera cli, makeinfo and info to create texinfo terminal friendly manuals for documentation of crates. A terminal based alternative to rustdoc, which is too htmlish to my taste.
Too early and whacky to share. Some info manual is generated, but very preliminary. When ready, I will share.
For the moment, that issue would be a nice to have. Not something I beg for.
@casey While not completely explaining what I am trying to do, you may get a vague understanding of why I am interested in various features such as the one I here requested.
I use justfiles in a way that is broadly similar to this use case:
https://github.com/gl-yziquel/mud-parse2D
As you can see, there is a just.d
folder with justfile fragments that I aim at sharing across various projects. This is an example usage of some somewhat bigger set of justfile fragments that I'd like to use in some form or another as a library of justfile fragments.
The justfile fragments are imported by the Justfile in the root folder.
In order to understand the use-case, I need to see a concrete example, i.e., example justfiles. However, those don't need to be the actual justfiles you are working on, or want to write, they can be simplified examples that just show the pattern you want, and the reason you want them. This is especially important because they help me figure out if there are existing features or workarounds that can let you so what you want. For example, here, if the desire is simple to hide certain recipes in the interface from users, you could use private recipes.
In order to understand the use-case, I need to see a concrete example, i.e., example justfiles. However, those don't need to be the actual justfiles you are working on, or want to write, they can be simplified examples that just show the pattern you want, and the reason you want them. This is especially important because they help me figure out if there are existing features or workarounds that can let you so what you want. For example, here, if the desire is simple to hide certain recipes in the interface from users, you could use private recipes.
And how do I do to get the private recipes listed with --list while keeping hidden the even more private recipes ?
And how do I do to get the private recipes listed with --list while keeping hidden the even more private recipes ?
So you want to be able to do just --features foo --list
to show recipes with feature foo?
Would be a start.
Ideally, I'd like to bail out when attempt recipes not in feature. But hiding/unhiding the discoverability would be better than nothing.
Please take your time to think the whole idea through. I'd hate to rush you through that.
The goal is the following: that just.d folder should in fact be a submodule. Many projects would share that git submodule. So I'd need a way to control the level of visibility / accessibility of recipes. Ideally through something like a feature mechanism.
One thing I'd like to do with my justfiles is gating recipes like one use feature gating in rust.
I'd like to do the following in just: