There is only one type of mixin

[dyoder]

I don't want to distinguish (either in our contributor docs or in our developer docs) between types of mixins. Or, at least, I don't understand the distinction.

To my mind, a mixin is simply a templatized launch description. A launch description, in turn, is three files: a Dockerfile, and service init file, and a config.yaml file.

You add mixins to your application repo, instantiation the templates in the process. This makes them normal launch descriptions.

As it happens, some mixins describe public endpoints and some don't. Some are defined so that they can run a broad variety of things and some are defined to run something quite specific.

There is no such thing as “template style”—all mixins use templates. I also don't understand the phrase “add-in style”—that's basically a synonym for mixin.

In theory, I can create a repo that contains only launch descriptions that run code that exists outside the repository. Most of the time, developers will want one more descriptions that run code that exists in the repository. That's why I wanted the example to include a mixin that falls into that second scenario, since that is going to be very common.

Is there some value in distinguishing between various styles of mixin? I don't see it, but maybe I'm wrong.

[freeformflow]

Okay. I understand, and I agree with you.

I was concerned that developers that are new to Huxley could get confused about the function of a mixin. Particularly since we are naming types of applications. Is this mixin modifying my code or placing third party code into my repository?

But starting the conversation by defining a mixin as a "launch description" makes all the difference to me. Mixin does not act upon your source code. It adds descriptions to your launch directory. These are descriptions of services (Docker containers) out there on your cluster, and what gets pulled into the container is specified in the mixin. The fact Huxley doesn't care what you pull is why it's awesome.

So:

• If you specify redis you get a container that pulls from Redis' public endpoint.
• If you specify node you get a container that pulls from your repository, and assumes it's a Node app.
• If you specify johnsmith/my_app_api you get a container that pulls from the GitHub repository belonging to johnsmith.

Huxley doesn't care. It shoves it into a container and runs it for you. Thank you, Dan.