Something that's tripped us up a bunch is that

EnvironmentDecorator

has

allow_multiple=False

. Typically someone sets an

@environment

in code, and then someone else tries to deploy

--with environment

and wonders why their environment variables aren't set. We've settled on working around this by writing custom decorators that modify an existing

@environment

decorator, instead of using

@environment

. This works, except when people apply the custom decorator without an

@environment

decorator and wonder why their environment variables didn't get set. Metaflow's behavior here seems counter-intuitive to me. I would expect multiple environment decorators to have the same effect as applying a single decorator whose

vars

attribute was determined by merging the

vars

of the individual decorators (with some room for discussion about handling conflicts). Would there be any interest in a PR to implement something like this? Or is the current behavior desirable? Or is it too late to change without breaking people's existing code?

Imho this seems reasonable. Multiple decorators are a more recent concept (all decorators used to be at most once) so I don’t think we made a conscious choice on this.

here's a little PR to allow multiple environment decorators, with a log message in case of conflicting values between decorators: https://github.com/Netflix/metaflow/pull/1785