When a file is included both ~ and $HOME are honored; however when a file path is used with the fake module keyword those strings are not handled.

Allow a statement like:
include path/to/files/*.just

or maybe:
include path/to/**/*.just

A justprep include file missing message does not set the exit status correctly. It should be set to 1 so that the follow-on execution of just is abored. This is true in the RubyGem version. Check the Crystal version to verify exit status is set correctly there.

As part of that exploration of alternate uses ...

What if JUSTPREP_FILENAME_IN and JUSTPREP_FILENAME_OUT were directories not files.

1. FIXME: I don't think they are actually checked to see that they are a file only that they exist.

2. Both would have to be directories or both files. when not then its an error

3. all files from the input directory are copied to the output directory with their included content. If a file does not have any inclusionary keywords then it is copied as is.

The command brew tap madbomber/brews is working with an install like brew install --build-from-source justprep

Greg was able to get bottles setup in his formula. I'm guessing that it had something to do with a github workflow action.

Near the bottom of the README.md file in the Limitations section

reads: ... file must be preset
should read: ... file must be present

Error messages our of justprep should use the same look and feel as those from just.

Part of that idea from the wiki on alternate uses.

Keeping the same concept of using envar for config ...

JUSTPRE_INCLUDE_MARKERS with default "on" || some truthy value
That would be the status quo.

When its "off" || some falsey value then the begin/end marker lines for included text are not inserted into the output file.

Consider a directory tree that looks like this:

home
├── main.just
└── projects
    ├── main.just
    ├── thing_one
    │   └── main.just
    └── thing_two
        └── main.just

Now suppose you have CD'ed into your thing_two project. What you may have is an explicit inclusion of all of the upper-level main.just files so that at the lowest level all the defined recipes are available. BUT if there was an implicit hierarchical layering in effect the upper level main.just files would be implicitly included.

However, sometimes implicit inclusion can lead to trouble. So is it worth considering?

With implicit layering you have access to all recipes that have been defined in the directory path with their lower-level over-rides.

You have the ability to do the same thing currently with explicit inclusions. A potential problem occurs when you move a directory from one path tree to another. But because of the explicit nature of the inclusions, the justfiles generated will include recipes that may no longer be appropriate.

Was expecting to see a new release binary for v1.2.4 when it was tagged but nothing happened.

setup "module" as a special keyword such that:

module path/to/my_mod/justfile

is replaced by:

module_my_mod := "path/to/my_mod/justfile"

and a new recipe for that module is added at the end of the current justfile that is being generated like this:

# Module my_mod
@my_mod what='' args='':
  just -f {{module_my_mod}} {{what}} {{args}}

Use an system environment variable $JUSTPREP_MODULE_KEYWORD to designate the keyword to be used for module processing.

Why not? It is a minor modification to support run.

Use a new system environment variable: JUSTPREP_FOR=run
Then in the fake module system use the content of $JUSTPREP_FOR as the command to execute. Will also need to customize the param to support pointing to a different Runfile than the default.

easy-peasy

Target this for release v1.2.4

Currently the software supports only a single-level inclusion process. Consider allowing the included files also designate files for inclusion. Lookout for cycles. Maybe limit number of levels to some small number to avoid stack overflows.

Look at adding a formula for homebrew to support the easy installation of the crystal version of the software.

The auto generated recipe for a module has a single line that invokes just and the specific justfile that may be outside of the local working directory hierarchie. Need to add "-d ." to the just command line parameters in order for the module recipes to be executed in the correct location.

Needs to look like this:

# Module gem
@gem what='' args='':
  just -d . -f {{module_gem}} {{what}} {{args}}

Hey @MadBomber. First off wanted to say thanks for working on a great project!

Appreciate you thinking about how to include other justfiles in a clean way that is usable right now!

I've been using it for a while now for my personal projects -- but some folks I have been talking with about justprep have a hard time to install it.

Would you be interested if I setup some automatic github actions to build binaries for folks (starting with the crystal one) whenever you cut a new release?

I would like to help out if possible, but first just 😉 wanted to check if that was something you would appreciate!

If not that is fine too. Appreciate your work!

There is some refactoring that can be of benefit. For example, create a method to standardize the error message format.

Also it might be interesting to extract out those methods between ruby and crystal that have common source code to both.

From a product POV, having a seperate repo that has multiple brew formulas does not make sense to me. The formula IMO, should be part of the product's main repo.