Implement a plugin model

[ehmatthes]

This project really needs to implement a plugin model in order to reach its full potential. To be specific, I'm planning to take these steps for the 1.0 release:

• Move this project to an org.
• Separate out the core, platform-agnostic part of the project. That will stay in this repository (moved to the org).
• Move each platform-specific deploy script to its own repository, in the new org.
• Implement a plugin system so that simple_deploy calls out to the appropriate plugin, based on the --platform argument.

This puts each part of the project on its own development cycle, which is really nice maintenance-wise. I want to keep these three original platforms inside the org, to make sure there are always three officially supported deployment targets. I'll add these as dependencies of simple_deploy, so installing simple_deploy includes support for these three platforms.

My main questions are around how to manage a third-party ecosystem of plugins, with security in mind. I know it's on users to evaluate a plugin before using it. But is there anything that we might want to think about now, in order to avoid any foreseeable issues? Maybe I'm overthinking this, but watching open source supply chain attacks is not fun when you're building a tool that's squarely focused on configuring deployments. It seems especially important to think about this considering that a core demographic for this project is users who are new to deployment.

Do you have any thoughts about this approach? I'd love to hear what people think while it's still relatively easy to make changes to the project's structure.

[jefftriplett]

I'm a fan of pluggy, one of the most flexible plugin systems I used. It took me a while to wrap my head around it, but the docs seem to be better today.

It's what these projects use:

• https://github.com/datasette
• https://github.com/simonw/llm
• https://pytest.org
• https://nox.thea.codes

I learned a lot by reading the dataset and LLM source code to get a better handle on how to wrap my head around it.

[ehmatthes]

I'm planning to use pluggy. I talked to Simon this weekend and he was highly enthusiastic about that approach.

[joshuadavidthomas]

I'll echo @jefftriplett and say that pluggy is probably what you want to use and that you should definitely take inspiration from how @simonw uses it.

Shameless plug, I wrote this POC after your DjangoCon 2022 talk about django-simple-deploy because I thought I saw the potential for a tool like this to leverage plugins and pluggy specifically to take the burden off the main project: https://github.com/joshuadavidthomas/pluggy-simple-deploy

[ehmatthes]

Thanks Josh! That's really helpful to see.

[jefftriplett]

But is there anything that we might want to think about now, in order to avoid any foreseeable issues?

That's the trillion-dollar problem. I would have a high bar and only recommend plugins you are comfortable with. Any time API keys and access tokens are involved there is potential for a bad actor.

That said, it should be relatively straightforward to vet them. Using @joshuadavidthomas's example, they will mostly have a one-file plugin like https://github.com/joshuadavidthomas/pluggy-simple-deploy/blob/main/simple_deploy_aws/simple_deploy_aws/__init__.py

I recommend sketching out your hooks first and getting some feedback on it. Then maybe we can break down where the biggest potential for harm might be. At the end of the day, there is a lot of trust involved with any project and third party library one installs.

[ehmatthes]

That said, it should be relatively straightforward to vet them. Using @joshuadavidthomas's example, they will mostly have a one-file plugin like https://github.com/joshuadavidthomas/pluggy-simple-deploy/blob/main/simple_deploy_aws/simple_deploy_aws/__init__.py

I don't think that's a good example. That's a dummy implementation, with no actual code. A better place to see what you'd likely have to vet is the Fly.io directory or the Platform.sh directory. The Platform.sh directory is important to look at, because it includes the beginnings of a platform-specific test suite. We've seen supply chain attacks that hide payloads in the test suite. So you have to ask, is this platform well-tested or is someone hiding an exploit?

[jefftriplett]

Sure. I think we have two different things in mind. I'm thinking about what an outside plugin looks like consuming the pluggy API vs. how you internally organize your builtins.

[joshuadavidthomas]

I understand your concerns around security, but I think I'm missing the core issue. Is it primarily about the risk of inexperienced users installing third-party plugins that could run malicious code? Like @jefftriplett said, you could say that about any number of the libraries we install and use on a daily basis.

Having a core set of officially supported platforms either within the main django-simple-deploy repo (as I sketched out here) or in separate repos within a dedicated "simple deploy" GitHub organization seems like the best approach. You can stress to users that while the core plugins are vetted and safe, they need to exercise caution and do their due diligence when using third-party plugins.

[ehmatthes]

Here's what I imagine the ecosystem would look like:

I'm not worried about anything that's inside the org, because we'll see all changes that happen there and can revert anything we don't like. Anything we bring into the org, we're making a conscious choice to review on an ongoing basis. However I would expect most plugins to live outside the org. That's where I'd be concerned about security issues.

I recognize there's security issues with all third-party software. I just wanted to talk some of these things through a little bit before building out this structure. Does this diagram look reasonable?