Is it possible to use the automation API in tandem with the Pulumi cli? My use case here is that I'd like to maintain parity with the expected usage of the Pulumi cli (eg my users being able to deploy with

pulumi up

and ensure all of Pulumi CLI's normal features keep working) but programmatically override certain settings, eg project name. The use-case for programmatically setting the project name is to ensure consistency for cross-stack refs. For example, I'd like for my users to provide

serviceName

and

scope

, then use that to generate the stack name, leading to being able to simplify importing via cross-stack refs

Yes, you can if that's what you want to do. But if all you want to do is to control the project name, you don't need to use the Automation API for that. Maybe just create a wrapper script (bash, PowerShell etc.) that simply calls the pulumi new command. Even with the Automation API or the wrapper script, your users could bypass whatever code you write for generating the project name and create a project that doesn't follow the naming convention. There isn't anything in the service that prevents them from doing so.

I'm not looking to properly force them to follow the standard, mainly just encourage it by making it more convenient to use the tooling I've laid out for them than to not. If they want to work around it and make their own lives harder in future, that's fine by me