Open maxdymond opened 4 years ago
I think that broadly makes sense.
Another possibility is to have the CLI part do configuration parsing + environment structure building, and passing them into the rest of floki. That's broadly the pattern I've been going for so far. To put it another way, all IO apart from running the container is kept to the CLI half, with the library just mapping from pure data to a running container.
I'm not sure the split will make it easier to test as such, but it might highlight any unintended interlacing of things. I don't know if the library would find much use in isolation.
(I had a brief wild thought that an additional frontend might take the VSCode style config and run containers using that - I'd never use such a thing, but a similar thing might be possible for emacs etc.)
In order to make floki easier to test on the Rust side, it might make sense to split floki into a library portion and a binary portion. This issue is to track what code would be in which part.
My naive first take on this:
binary:
library:
Would be interested in hearing thoughts... @rlupton20?