-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider not always printing mutagen related information #13
Comments
That's a fair point, for sure. The quick solution here might be to just disable any Mutagen session output if the Would that work for your use case? Later down the road it might even be possible to include Mutagen session information as part of that JSON once Mutagen starts making JSONified session information available. If you're parsing the JSON, your parser can probably just ignore it. |
That would only work to some extend. For instance, we use to Hence I'd rather be in favour of some slower yet cleaner patch. Is there a reason why not? Sorry if my last message made it look like I'm in a hurry: I'm not, I just have some time now to help and may not have this amount of time later 🙂 The later down the road plan seems nice indeed, maybe following the |
Ah, okay, I see your point. Yeah, using I agree with your idea of using an environment variable. It's more consistent with Mutagen itself (which has a number of environment variables) and it's less tedious to use. It's also way easier to implement. If you'd like to implement it, I'd be more than happy to merge it. You'd just need to wrap this code block in the appropriate check. The biggest issue is just nomenclature. I'd say maybe call it I can't think of any other locations in the output where Mutagen adds output that you'd want to disable, so I don't think the variable needs to be more generic or flexible than that. I guess one question would be whether or not you'd want to exclude the Mutagen sidecar container from being shown in the I haven't had a chance to update this repository's contributing guidelines yet (I'll do it tomorrow), but you can follow the Mutagen guidelines for now. Nothing too onerous, but just try to keep the commit message consistent with this guidelines (e.g. |
Got it working as you expected (well you kind of gave most of the implementation away 😄)
However, It looks like skipping the whole block would make it impossible to fail if there are errors related to mutagen. Hence I've provided a Here's the PR: #14 |
Hey,
First time contributing so first of all: thanks for the nice tool!
In my company we're users both of the original docker-compose for linux users and mutagen-compose for macos users. Unfortunately, the output is not the same, which makes it really bothering to script anything. For instance:
I'm really only expected the last line here. I've looked at the codebase, and there is not way to avoid this output (well
> /dev/null
ortail -1
would work, but I'd have to know beforehand that I need only one line, or none).IMHO there should be a configuration available. Either ENV, which would be my favourite since it allows to set it beforehand and then work as if we were really using
docker-compose
, or some flag, which would be OK as well (we could definealias docker-compose='mutagen-compose --silence-mutagen'
for a similar behaviour)Anyway, I'd be glad to help on that one if that makes it ship faster 🚀
Otherwise, I'll wait :)
Cheers,
Ulysse
The text was updated successfully, but these errors were encountered: