Thinking about Crane 2

[michaelsauter]

Recently I have been thinking about what a version 2 of Crane could be. Parts of this has already been covered in #186, but I would like to collect more thoughts here - and hopefully get some feedback!

What I don't like about Crane currently:

• Mixture of build and runtime functionality. In Extract build related functionality #186 I was suggesting to extract the build related part, now I'm thinking I might actually just remove it altogether. I don't see it as a goal to have feature parity with Docker Compose, and what Crane currently offers in terms of building images is so small it can easily be handled by a script. The difficulty with extracting is that it would need to share quite a bit of the code, and that it would take time to maintain
• No way to specify CMD via the CLI. I would like to be able to specify a different process for the container(s). That is currently impossible since there can be multiple targets.
• Too complicated cascading (we probably don't need the different types)
• Odd behaviour of lift - I can't think of a use case where you wouldn't want to pass -r to it

Possible changes:

• Remove provision and push commands
• Simplify cascading to dependencies/affected. Possibly with a more fine-grained linked/linking since that seems to be the most common use-case
• Map lift to pull//remove/run
• Have only one target. That allows users to specify a process to run as the second argument
• Maybe that one target can be a bit more complex. E.g. a+b to target both a and b. One could also see affected containers as some sort of "dynamic group", which might be nice to specify as a target as opposed to via flags, e.g. a+linked or if we want to use a different char, a&linked. To exclude targets, something like a^b could work.

Any feedback welcome.

[dreamcat4]

Hello @michaelsauter I just wanted to check that you are not planning on removing the crane create cmd? It should not be, yes?

[michaelsauter]

@dreamcat4 Of course not, create is staying for sure. BTW, I still haven't decided on whether some build functionality should go or stay. At this stage, these are just thoughts, no concrete plans.

[ncadou]

Right now I'm not using the build functionality because, as you said, it's too limited. The ability to specify a command as an alternative to a Dockerfile would go a long way in my case.

[missedone]

maybe in V2, can consider use golang docker client, e.g. https://github.com/fsouza/go-dockerclient, so that we can get rid of the dependency of docker bin.
i can take a look if you're interested

[dreamcat4]

@missedone Actually I like that crane calls the docker bin... because it means the -v switch shows exactly which docker commands are being run. That is very practical / useful.

I'm not strictly opposed to having both, so long as that feature ^^ remains intact.

But also: To help justify the reasoning, what is the specific (real world) problem(s) you are trying to solve? AFAICT almost all people will also have the docker binary too because certain commands are not being offered by crane, they are provided by docker bin instead. The two tools are supposed to be used in tandem (at least the typical cases, development environment).

[missedone]

@dreamcat4 no particular tech problem i have.
i'd like to ask the QA team to use crane to quick spin up the test env, they are lack of docker knowledge, i want to make the getting start more easy that QA team only need to get the crane executable rather than install docker bin as mandatory condition

[michaelsauter]

@missedone @dreamcat4 That change won't happen. I started out using the Docker binary because it was easier, and also because it was easier to add support for new features (since we don't need to wait for the Go client to be updated). Initially I wanted to change to the Go client, but there's no real need, plus verbose output of Crane is really really nice IMHO.

For what's to come in version 2, please see #208.

[jesper]

FWIW: I'm using the build/provision feature on a daily basis would be happy to see it stay. Although I agree it wouldn't be too tough to script, it is one of the reasons I picked crane over compose/maestro.

[michaelsauter]

@jesper Good to hear. I have since decided that I don't have the capacity to support another tool besides Crane. Therefore, I'm going to leave the basic support for building/pushing in.

[michaelsauter]

Progress at #212.