Hello, I put together a document describing the proposal for an

experimental-deploy

goal and a PoC implementation for the Helm backend: https://docs.google.com/document/d/17wZRjiIxM5918ybC_0EnKY42qwd47-1ZporBdua8vRQ/edit?usp=sharing My apologies for how drafty the document feels, having a mix of plenty at my plate and family issues at the moment so I couldn’t dedicate much time to it. Hope that the document plus the PoC Pull Request are useful to trigger a conversation.

Looks like it requires individual access permissions?

sorry, didn’t notice it, will open the access to it

+1 for this. But, I'd be remiss if I didn't mention a conversation @careful-address-89803 and I had briefly re: the deploy goal for the Ansible plugin we're building. In short, I think it comes down to semantically describing and defining what a

deploy

goal means in the Pants world, and if something else would work well enough. A while back, I created this

deploy

goal: https://github.com/sureshjoshi/pants-plugins/blob/main/pants-plugins/experimental/ansible/deploy.py But as I think about it more, I realized in the

ansible

case,

deploy

only really meant "run this tool on these files/packages and it will magically provision a server or localhost", so

./pants run

on an

ansible_deployment

target could arguably work as well. Anyways, I got to the point where I'm not for or against anything on this, but I did reach a semantic existential crisis.

that's a really good point, in the initial implementation we did at my company we called

install

as it correlated with

helm install

and it could fit well in case we wanted to instead a Go binary too (which would have a different behaviour for the

run goal

A run goal would in fact fit well with

helm_deployment

targets so now I falling into the same semantic crisis. Think the key difference is the ability to trigger the

publish

goal for the deployment dependencies, but not sure that's a general enough case worth pursuing.

“it could be part of `run`” is an argument against a lot of side-effecting goals, including

publish

. but i think that an argument can still be made that unifying a few different semantically similar implementations (ansible + helm, for example) behind a dedicated goal will frequently make sense, primarily because it encourages consistency: 1. if the answer to “how do i publish/deploy” is “write a

${lang}_binary

target with particular arguments and then use

run

on it”, then there isn’t necessarily anything encouraging consistency across the implementation of those binary targets. 2. from a type safety perspective, if

run

usually means running user code, it’s odd for

run

to do something else entirely for ansible/helm (because it means that even if you have empty input files, something might happen). but yea: worth being cautious: thanks for the proposal! will read in the next few days.

@witty-family-13337 can you give commenting permissions on the doc?

Good point, I keep forgetting about the

::

- definitely not what you want to casually run for side-effect laden goals!

hey folks, adding to what SJ said, I don't think there's really a case where "run" is strictly necessary as a goal. For some tools, there's a need for publish and do-effects. For example, Helm can both publish charts to a repository or deploy them to a cluster. Helm, Ansible, and Terraform don't have 2 types of do-effect tasks which would require separate goals. Some tools sortof have that with a synthesis stage. For example: Azure Bicep can be synthesised to ARM templates which are also a useful resource in themselves. But maybe that is more appropriately a codegen/package target, the way compiled code is for JVM targets. OTOH, I agree with Benjy that we should be signaling that these actions are going to prod. (Although sometimes publish does that too; but publish also signals that!) Also, I think there are many other tasks which would appreciate a "deploy" goal more than a generic "run" goal. For example, the Python AWS Lambda and Python Google Cloud Function targets have a package goal, but not the ability to actually upload that to their runtime. For another example, I think "running" a simple Kubernetes manifest wouldn't make much sense until someone explains that it's because there isn't a deploy goal. So my opinion (FWIW) is that a "deploy" goal is not strictly necessary but would help usability.

@happy-kitchen-89482 the document should now have commenting permissions. Sorry again.

Hey, so I think this is good to go forward on an experimental basis!

hi Benjy, sorry for the recent radio silence, had some family issues and took some time off to deal with those