search

julien-duponchelle / docker-osx

Fast and easy installation of Docker on OS X
1.02k stars 70 forks source link

Configure docker instead of wrapping it #25

Closed shykes closed 10 years ago

shykes commented 10 years ago

I don't like that this wraps docker. I especially don't like that it adds non-standard commands that will confuse people as to what is supported by docker itself and what is not. If you're going to call it docker, make sure it's really docker (ie no modifications). Otherwise call it something else.

My recommendation:

If you do this I can merge it upstream and make it the official mac installer for docker.

julien-duponchelle commented 10 years ago

I understand you. And i add a warning about non official status of the project. I hope people will not confuse this with the futur official binary. Don't hesitate if you want me to make more change.

I agree about docker command installed in path should be the original command.

What did you think about a command which start a new shell with all environnement variable set (like ssh-agent command) and start the VM.

shykes commented 10 years ago

That could work, it would need some experimentation.

By the way, I should have started by saying: thanks for putting the effort to do this :)

On Fri, Jan 3, 2014 at 12:14 PM, Julien Duponchelle < notifications@github.com> wrote:

I understand you. And i add a warning about non official status of the project. I hope people will not confuse this with the futur official binary. Don't hesitate if you want me to make more change.

I agree about docker command installed in path should be the original command.

What did you think about a command which start a new shell with all environnement variable set (like ssh-agent command) and start the VM.

— Reply to this email directly or view it on GitHubhttps://github.com/noplay/docker-osx/issues/25#issuecomment-31550117 .

cap10morgan commented 10 years ago

This all makes sense, but please keep the ability for the user to alias docker-osx to just docker. That is, keep the code that forwards Docker's built-in commands to the underlying docker client binary.

shykes commented 10 years ago

On Fri, Jan 3, 2014 at 1:09 PM, Wes Morgan notifications@github.com wrote:

please keep the ability for the user to alias docker-osx to just docker. That is, keep the code that forwards Docker's built-in commands to the underlying docker client binary.

This is precisely what I'm asking not to do. May I ask why you feel that you need this?

cap10morgan commented 10 years ago

@shykes Not exactly. You're asking them not to wrap Docker by default which makes perfect sense. But I, as a user, would like the ability to alias this command in my shell as just docker so I don't have to care which one I use to do what. This is a common pattern employed by scripts that add commands to underlying utilities (see, for example, https://github.com/github/hub).

shykes commented 10 years ago

On Fri, Jan 3, 2014 at 1:14 PM, Wes Morgan notifications@github.com wrote:

@shykes https://github.com/shykes Not exactly. You're asking them not to wrap Docker by default which makes perfect sense. But I, as a user, would like the ability to alias this command in my shell as just dockerso I don't have to care which one I use to do what. This is a common pattern employed by scripts that add commands to underlying utilities (see, for example, https://github.com/github/hub).

I don't understand what you mean by "not have to care which one I use to do what". With the changes I recommend, there will be literally nothing left for the wrapper to do which the one-time configuration doesn't. It will be exactly the same for you.

The only difference for you is that the namespace of docker-osx commands and docker commands will be correctly separated into their respective command-line tools, instead of shadowing each other and possibly conflicting, which is an accident waiting to happen.

cap10morgan commented 10 years ago

Well, since it's just halt and ssh that docker-osx adds (for now), it's not a big deal.

But personally I prefer docker halt instead of docker-osx halt and would like to be able to use it that way locally if I so choose (and whatever other commands may be added to this down the road).

shykes commented 10 years ago

You are free to set the aliases you want, and Julien is free to do whatever he wants with docker-osx, such is the beauty of open-source... But now you guys have my opinion as the author of docker on the matter.

Setting these aliases is a bad idea and you shouldn't rely on it - otherwise you will regret it the day 1) docker releases a 'halt' or 'ssh' command of its own, or 2) you start writing or using tools which only work with your alias instead of being compatible with any docker installation, or 3) you want to use another 3d-party tool which also wraps docker with a different implementation of 'docker ssh' or 'docker halt'.

On Fri, Jan 3, 2014 at 1:40 PM, Wes Morgan notifications@github.com wrote:

Well, since it's just halt and ssh that docker-osx adds (for now), it's not a big deal.

But personally I prefer docker halt instead of docker-osx halt and would like to be able to use it that way locally if I so choose (and whatever other commands may be added to this down the road).

— Reply to this email directly or view it on GitHubhttps://github.com/noplay/docker-osx/issues/25#issuecomment-31555972 .

julien-duponchelle commented 10 years ago

I agree with @shykes until it was just a way to play with docker locally it was not a problem. Since a few day the project start to get more visibility (i'm the first surprised by this) and people start to use it in their everyday process it start to be a potential issue.

I hope one day part of this hack can be merge into upstream project. That why this recommendations are very important.

bfirsh commented 10 years ago

I agree with you, @shykes. I'm not sure I like the idea of a hacky shell script, and I'm also interested in it being able to support other platforms that Docker doesn't support (e.g. BSDs).

I'll have a go tomorrow at writing a separate thing to manage a Docker VM. It'll probably behave a bit like Vagrant, but with its sole purpose being to run boot2docker inside Virtualbox.

julien-duponchelle commented 10 years ago

I start a branch boot2docker with some night work :)

The boot2docker boot but i have some trouble with network setup.

bfirsh commented 10 years ago

The beginnings of a project that'll configure Docker instead of wrapping it: https://github.com/bfirsh/virtualdocker (Note: does not work yet. ;)

julien-duponchelle commented 10 years ago

@shykes I push a new release with the command and renamed and stop wrapping docker command. Next step use boot2docker instead of ubuntu.

cap10morgan commented 10 years ago

This is a step backwards in usability from the old wrapper approach (for what I see as pretty dubious fears of things that are not likely to occur, and are easily worked around if they do).

With the old approach, I could get up and running by doing this:

  1. Download docker script to ~/bin
  2. Run docker version or any other docker command, and it bootstraps itself and runs the command
  3. Docker now "just works" without me having to do any setup, even if I exit my shell, reboot my computer, etc.

Now I have to do:

  1. Download docker-osx script to ~/bin
  2. Run docker-osx shell
  3. Run a docker command.
  4. If I exit this shell or launch a new one, I now need to run docker-osx shell first before Docker will work.

Am I missing something?

shykes commented 10 years ago

I understand how you would find that annoying :) Here's what I'm actually suggesting:

  1. Download docker-osx and run "docker-oxc install" once.
  2. Run "docker-osx up" once at boot (for example in your startup items)
  3. Use docker normally

No need to run a special shell. The only configuration necessary is setting "DOCKER_HOST" in your shell, which "docker-osx install" can take care of for you.

On Mon, Jan 6, 2014 at 10:06 AM, Wes Morgan notifications@github.comwrote:

This is a step backwards in usability from the old wrapper approach (for what I see as pretty dubious fears of things that are not likely to occur, and are easily worked around if they do).

With the old approach, I could get up and running by doing this:

  1. Download docker script to ~/bin
  2. Run docker version or any other docker command, and it bootstraps itself and runs the command
  3. Docker now "just works" without me having to do any setup, even if I exit my shell, reboot my computer, etc.

Now I have to do:

  1. Download docker-osx script to ~/bin
  2. Run docker-osx shell
  3. Run a docker command.
  4. If I exit this shell or launch a new one, I now need to run docker-osx shell first before Docker will work.

Am I missing something?

— Reply to this email directly or view it on GitHubhttps://github.com/noplay/docker-osx/issues/25#issuecomment-31670820 .

cap10morgan commented 10 years ago

@noplay Any plans to implement this in the way @shykes describes above?