Allow mutation of services after or during project creation

[bfosberry]

I have a need to inject additional volumes and environment variables, as well as edit some port mappings depending on additional configuration parameters.

My current method of achieving this is to cast APIProject -> Project and access p.ServiceConfigs, which is not ideal. My gut reaction is to add a "GetServiceConfig" function to the APIProject interface to allow this, but I'm not happy with exposing the config package out via the interface. Another option would be to have something like a func MutateEnvironment(service string, func(currentEnv []string) []string), or maybe make a public service config interface for this kind of mutation. The ServiceConfig is basically just a struct with config params of base data types, so an interface might be overkill, maybe exposing it would be ok.

WDYT?

[joshwget]

I'm not sure why exposing the config package would cause any problems. It sounds like the best solution here.

I've ran into a lot of similar limitations with APIProject. I've actually reverted back to using the Project struct in our fork of libcompose because it's easier to work with.

[wagoodman]

This doesn't help with all possible changes to the config that you can make. For instance, if you want to modify a volume or add a service to a network, then changing the config would not help. For instance, when using Load() this would initialize the volume/network data structures, so changing the config at this point would do nothing (and is a bit misleading): https://github.com/docker/libcompose/blob/6bb86d53fa21f155e2daafa64796dbca61733df5/project/project.go#L248-L267

It would be desirable to recreate objects if the config changes, or to allow the user to reinitialize the data structures on demand.