maybe get rid of dhyve env
nlf opened this issue · comments
so this is just a thought i had, but i wanted to write it down so we could talk about it..
if we add a dependency on socat, we can actually create a unix socket on the host osx system that would automatically forward to the running vm's docker daemon, which would totally eliminate the need for the user to ever call eval "$(dhyve env)" and most things would just work™
worth the extra dependency for the simplicity?
Will that work for multiple VMs, too?
ah, you're right, no it won't. maybe it could be an optional thing and associated with one specific vm. or we could create a socket for each vm and let the user choose which is their default..
to elaborate, if we were to create ~/.dhyve/machinename/docker.sock then when the user chooses a default we could just symlink it to /var/run/docker.sock for them.
Sounds fair.
Users need one more step as same as $(dhyve env) though.
it would only be a one time step though, rather than on every login, so that's a small win
Yeah.
On the other hand, I like it because it looks more seamless to use Docker on Mac.
that was my main thought, no more mucking with environment variables.
OK.
Is there any solution for it instead of socat?
I don't like another dependency actually.
i think we can make it work with netcat also, which is bundled with osx, it's just a little more awkward
👍
need to test this more thoroughly before i decide whether or not to stick with it, but i have managed to make it work
hmm.. this doesn't work great with just netcat. on top of having to create a fifo as well as the socket, it's pretty unreliable. especially with regards to interactive shells.
socat works great, but adds another dependency.
i guess it comes down to a question of either installing socat, or just keeping dhyve env around.
I prefer dhyve env for now.
i agree, until we come up with a better solution i think dhyve env stays