Rename 'install' command as 'init'

[dpordomingo]

fix #11

After #2, the install subcommand is not only used for the first time you run source{d}, but also to come back to a dir that was used previously.

As described in #11 I choose init, but I'm opened to suggestions.

[carlosms]

👍

[smacker]

After more thinking a bit more about it I favor up instead of init. I also think it should be recommended way to start Source{d} instead of init and then start.

The main difference between up and start in docker-compose that the first one recreates containers if they were updated. So if an user downloads new docker-compose.yml or makes manual changes up must be run, not start or changes in yml won't have any effect.

The name init sends different message as you have to run it only once for each dataset.

[carlosms]

To me both up and init make sense, and to me they both give a similar message. I'm ok with any.

The main advantage I see for up is that for someone familiar with docker-compose the meaning and implications are automatically clear without having to go through our docs.

So from my side 👍 if @dpordomingo doesn't mind to change the PR.

About

I also think it should be recommended way to start Source{d} instead of init and then start.

I thought this was already the case, current install is the only thing you need. If the docs give the idea that you need to do install + start we should make it clear that start is only useful after a stop.

[smacker]

Hm. On another hand for install (or init or up) user have to pass dir to repositories which is annoying. Which means better let user execute this command only once. So then I'm indifferent to init or up.

But we definitely need to think a bit more about how to re-create containers.
It is easy with only update command. But we also have sourced compose download and sourced compose set which right now don't work as expected. (At least not as I expect)

[carlosms]

I created a new issue so we don't loose this conversation about missing container recreate: #27

[dpordomingo]

Given the current state of the discussion, with no strong opinions about using up instead of up, and given that we have three use cases, I'd merge with init, so it could be:

• init: to initialize the sandbox with the passed working directory,
• to start the services with the current working directory,
  • up: after being updated (e.g. downloading a new docker-compose.yml)
  • start: after being manually stopped with stop