Implement loading justfile from stdin

[drzymalanet]

I think it would be nice to have the possibility to pipe justfiles into just, like so:

cat input.txt | just --dump --justfile - > output.txt

It would work by detecting a special symbol "-" as the -f / --justfile argument.

Benefits:

• Some code editors like helix require this in order to make auto formatting to work,
• Many command line tools work like this and it seems it will not hurt to have,

The plan:

1. Move Search{} functionality into Source{}
2. Implement Source::from_stdin()
3. Add "-" detection to the argument parser.

Here is the first of the commits, more commits will be added while work progresses.

[casey]

This seems reasonable, but this PR looks a bit too complicated and I think some of the changes are unnecessary.

I would create two new SearchConfig variants, WithStdin, and WithStdinAndWorkingDirectory, and handle those two cases separately in Search::find.

[drzymalanet]

@casey I have added the variants, now we need to change Search.justfile type because it is a PathBuf which does not fit to the stdin stream. It seems to me that changing it to an Rc<dyn std::io::Read> or a custom JustfileSource would be some options. What do you think?

[casey]

There are two options I can think of:

1. Add an additional field to Search, which is a string containing the loaded source
2. Make Search::justfile an enum, like JustfileSource

I would try out 1 first and see how it looks and see if it causes any problems, or requires a big refactor.

[drzymalanet]

Sorry for closing and reopening. It was by mistake.

@casey Please have a look at the new commit. I have added a JustfileKind enum to the Search struct. It does not feel right, but I have no idea how to make it better without a bigger refactor. Let me know what you think.

[casey]

This looks like a good approach to me!

[drzymalanet]

Hi @casey I have changed a little the implementation of this PR. Previous approach did not felt right for me. I think the new approach makes more sense. However, I stumbled upon a failing integration test: working_directory::justfile_without_working_directory. It seems it runs the command in a subshell, which makes it hard to find out what's the problem. Any advice on how to trace this?

Let me know what you think about the new changes.

Thanks!

[casey]

I think this should just be justfile, since the type is already a path.

[drzymalanet]

I agree. Fixed.

[casey]

I can't really review this PR yet, because it doesn't actually implement reading justfiles from stdin, it's just kind of preliminaries, which, without seeing the implementation, I'm can't give good feedback on.

[casey]

These functions are kind of footguns. If the justfile was read from stdin, then there is no path or directory to the justfile. I understand that these are kind of compatibility shims, but I think the code just has to be adapted to deal with the fact that the justfile path might be None.

[drzymalanet]

My reasoning is that you still need to know the working directory even if you load the justfile from stdin. On the other hand, many functions don't need to know both the working directory and the optional justfile path. That's what this function does. It abstracts away the justfile directory over the Search struct. I don't have strong opinion on this, but the abstraction seems reasonable. How do you see it?

[casey]

working_directory is fine, and should always be set. It's justfile and justfile_directory that I think are the issue, since there is no justfile, and no directory containing it.