Hello, I put together a document describing the pr...
# development
Hello, I put together a document describing the proposal for an
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.
🔥 1
👍 4
Looks like it requires individual access permissions?
sorry, didn’t notice it, will open the access to it
anyone with the link should have access now
+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
goal means in the Pants world, and if something else would work well enough. A while back, I created this
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
only really meant "run this tool on these files/packages and it will magically provision a server or localhost", so
./pants run
on an
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
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
targets so now I falling into the same semantic crisis. Think the key difference is the ability to trigger the
goal for the deployment dependencies, but not sure that's a general enough case worth pursuing.
👍 1
“it could be part of `run`” is an argument against a lot of side-effecting goals, including
. 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
target with particular arguments and then use
on it”, then there isn’t necessarily anything encouraging consistency across the implementation of those binary targets. 2. from a type safety perspective, if
usually means running user code, it’s odd for
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.
👍 3
@witty-family-13337 can you give commenting permissions on the doc?
FWIW I think
makes sense as a standalone goal, not
, e.g., to avoid
./pants run ::
doing dangerous you didn't intend...
🤯 1
OK that won't work today, but let's say
./pants run path/to/thing.py
That command line does not adequately convey that you're about to change production!
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!
The helm post-render trick seems like the way to go
hi Benjy, sorry for the recent radio silence, had some family issues and took some time off to deal with those
glad to know that the proposal looks like a sound approach, will polish the original PR and getting it read for review