-
First of all, thanks for such an amazing amount of work. This makes things so much easier. Particularly, a huge thanks for the work you did on xformers. Another big selling point for this repo is that you keep it up to date. I know simplicity is the key aim for this project, but would it be worth abstracting away some of the mount point settings into ENV variables (as an .env file)? I'd like to be able to set the data and model directories on different drives or in different local directories and not have to worry about merge conflicts. So rather than having our own custom compose and docker files, we'd simply pass an additional flag to compose (in addition to --profile) that uses a .env file that won't cause any conflicts? More a convenience obviously, and happy to go the custom file route. But definitely open to the best ways others have done this if it's not on the cards. Thanks again for all your hard work. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
You can always create services:
auto:
volumes:
- /some/folder/you/want:/data
- /some/other/folder:/output This won't have any conflicts and it changes only rarely, works with updates, no need for custom dockerfiles, unless you need a really different setup of the folder hierarchy. I hope this suffices for your use case. |
Beta Was this translation helpful? Give feedback.
-
Why have I never even heard of docker-compose-override?! |
Beta Was this translation helpful? Give feedback.
You can always create
docker-compose.override.yml
and update the mounts in it.This won't have any conflicts and it changes only rarely, works with updates, no need for custom dockerfiles, unless you need a really different setup of the folder hierarchy.
I hope this suffices for your use case.
If you could give me more info on what you need maybe I have some ideas /solutions.