Container kinds (stages)

[tailhook]

It looks like I have some pattern for the containers, basically for each microservice I have

# Fetch latest dependencies, to create requirements.txt
app-freezer:
   setup:
  ...
   -  !Py3Install [pkga, pkgb, pkgc]
# Development container for app
app:
  setup:
  ...
  - !Py3Requirements "requirements.txt"
# Deployment container for app
deploy-app:
  setup:
  - !Container app
  - !Copy ...

Well, the first two containers is a boilerplate, that is going to be fixed by #114, but fixing the issue #114 is not easy. And it probably can't be fixed for all the cases. Only for few well-known package managers.

What I'm thinking for is adding some stages, like (very sketchy):

app:
  pre-build:
    setup:
   ...
    - !Py3Install [a, b, c]
  setup:
  ...
  - !Py3Requirements
  deploy:
  - !EnsureDir ..
  - !Copy ..
  - !Copy ..

Or maybe like this:

setup:
- !Stage pre-build  # -----------
- !Ubuntu ..
- !Py3Install [a, b, c]
- !ResetStage "pip3-requirements.txt -> requirements.txt"
- !Stage normal  # --------------
- !Py3Requirements "requirements.txt"
- !Stage deploy  # --------------
- !EnsureDir ...
- !Copy ...
- !Copy ...

This would probably allow to organize containers in groups and understand the role of each container.

The downsides of this comparing to #114:

1. The PyFreeze may provide better upgrade path (I mean upgrade one of the packages in configuration). This one would probably work only in "update everything" mode
2. Probably less clean solution for the task

The upsides:

1. More use cases can be covered
2. Easier to implement than #114
3. Straight path for deployment containers
4. Shorter to write for many tasks (comparing to container nesting)

Thoughts? Ideas? Any other good use cases for functionality?

[popravich]

The idea sound reasonable. As for sample configs -- can't really say

[tailhook]

Another use case here is to have a "cached" version of container, which just downloads tarball elsewhere.