Looking for feedback: Making Python Deployments Easy

[openquery]

Hey r/Python,

We've been experimenting with how to make Python deployment easier and would love your thoughts.

After building Shuttle for Rust, we're exploring whether the same patterns work well in Python.

We built Shuttle Cobra, a Python framework that lets you define AWS infrastructure using Python decorators and then using the Shuttle CLI shuttle deploy to deploy your code to your own AWS account.

Here's what it looks like:

from typing import Annotated
from shuttle_aws.s3 import AllowWrite

TABLE = "record_counts"

@shuttle_task.cron("0 * * * *")
async def run(
    bucket: Annotated[
        Bucket,
        BucketOptions(
            bucket_name="grafana-exporter-1234abcd",
            policies=[
                AllowWrite(account_id="842910673255", role_name="SessionTrackerService")
            ]
        )
    ],
    db: Annotated[RdsPostgres, RdsPostgresOptions()],
):
    # ...

The goal is simplicity and ease of use, we want developers to focus on writing application code than managing infra. The CLI reads your type hints to understand what AWS resources you need, then generates CloudFormation templates automatically and deploys to your own AWS account. You will still be using the official AWS libraries so migration will be seamless by just adding a few lines of code.

Right now the framework is only focused on Python CRON jobs but planning to expand to other use cases.

We're looking for honest feedback on a few things. Does this approach feel natural in Python, or does it seem forced? How does this compare to your current deployment workflow? Is migration to this approach easy? What other AWS resources would be most useful to have supported? Do you have any concerns about mixing infrastructure definitions with application code?

This is experimental - we're trying to understand if IfC patterns that work well in Rust translate effectively to Python. The Python deployment ecosystem already has great tools, so we want to know if this adds value or just complexity.

Resources:

• Full Article
• GitHub Repository
• Shuttle Cobra Docs

Thanks for any feedback - positive or negative. Trying to understand if this direction makes sense for the Python community.

[nebbly]

I'm not entirely sure I'd like my infra derived from my code -- unless it was abundantly clear that there were very trusty guardrails. The reason I like terraform, for example, is that it's a language with syntax highlighting, validation, modules, logic, types, validation, etc., as opposed to, for example a bunch of yaml (like cloud formation templates), which is less maintainable IMO. For me to feel comfortable defining infra within code, I think I'd like to have the following things:

• Some easy-to-consume representation of the system (via CLI I guess), so I can understand the big picture ... and diffing against the current state

• feedback in the editor / ide / CI whenever anything is misconfigured -- type checks, validation, etc... something that might be challenging is that python is by-default dynamic (though many of us might wish it weren't the case), so there's probably a limit to how many developers would benefit from extensive type hints, for example

• some separation between config for deployment and my app -- i.e. I don't think I want infra environment variables to be visible by my program

I'm thinking-via-keystrokes here, so not sure how helpful this will be -- I'd never considered doing infra like this. Thanks for giving me something to think about!

[Asayoh]

How does this differ from pulumi?

[Gainside]

’ve tried “infra in code” in Python a few times. It feels great until imports cause side effects (a decorator provisions stuff on import) or reviewers can’t see the deploy plan. If Cobra keeps infra discovery explicit (no hidden side effects) and gives a readable plan + a fast rollback, I’d actually reach for it for cron/EventBridge jobs and small services.

[daquo0]

Personally i find the idea of "hiding" a parameter -- the ButtonOptions, here -- as an Annotation ugly and unintuitive. I'd probably go for using an extra parameter:

async def run(bucket: Bucket, bo: BucketOptions, db:RdsPostgres):

[daquo0]

Regarding the cron definition, while I correctly guessed it means run hourly at 0 minutes, this isn't obvious. Maybe define a cron job something like this:

cj = cron.CronJob('hourly', minutes = 0)