I created my first project with

pulumi new aws-python

. After looking at it, I realized I wanted to use the native python bindings for this, so I `rm -r`ed the directory and attempted to recreate it with

pulumi new aws-native-python

. This isn't letting me do so though because the old project still exists in pulumi.com's state. I'm not sure how to delete it though because there doesn't seem to be any way to do that from the web ui, and I don't have any of the configuration files that told the cli about the project and stack. (There are no resources in it - I never ran

pulumi up

- so it's just the project itself that I need to delete)

pulumi destroy

first to destroy all the resources

right, I can't because I don't have the files that let the cli identify the project:

┌─[jamesph@Jamess-MBP] - [~/Documents/winfrastructure] - [Mon Sep 12, 04:06]
└─[$]> pulumi stack ls
error: could not detect current project: no Pulumi.yaml project file found (searching upwards from /Users/jamesph/Documents/winfrastructure). If you have not created a project yet, use `pulumi new` to do so: no project file found
┌─[jamesph@Jamess-MBP] - [~/Documents/winfrastructure] - [Mon Sep 12, 04:06]
└─[$]> pulumi stack rm staging
error: If you're using the --stack flag, pass the fully qualified name (org/project/stack): no Pulumi.yaml project file found (searching upwards from /Users/jamesph/Documents/winfrastructure). If you have not created a project yet, use `pulumi new` to do so: no project file found

You can also do this through the UI, if a stack was created (as opposed to just the project). It's on the settings page. Also FYI, you don't need to do this. aws and aws-native can live in the same project, you just need to add the extra dependencies and create another provider.

yeah, I was about to just add it, and then I figured since I hadn't really started anything yet it would be easier to just start over. I forgot that there was a remote state created 🙂

Projects are extremely lightweight in Pulumi state. They're no more than a namespace, really.

I see

FYI, the "native" in AWS Native doesn't refer to bindings, per se. It means that the provider uses the native API of the cloud provider, as opposed to using a Terraform provider to help formulate the API request. In AWS' case, the native provider works off the new AWS CloudControl API. However, not all resources in AWS have been implemented yet by the CloudControl team, so you'll have to fall back to the Classic provider for some resources. Mixing providers like this in a Pulumi program is idiomatic and I recommend folks check out AWS Native once they're comfortable with the Classic Provider.

I understood the terraform vs not part, but my thought was that -native was the path going forward and so I should start there and only use the classic shims if I need to. Why do you recommend doing classic instead?

I only recommend sticking with Classic for total beginners just so they don't get confused with multiple providers. Sounds like that shouldn't be a problem for you. Please do let us know how it goes with AWS Native!

Mostly ok so far! There are I think three things I've encountered, which I'm not entirely clear yet which are expected and which are not: 1. There's some name weirdness in some of the docs. So for instance on https://www.pulumi.com/registry/packages/aws-native/api-docs/ecs/taskdefinition/#container_definitions_python , it says it takes a list of

TaskDefinitionContainerDefinition Args

but down on the page it says

TaskDefinitionContainerDefinition

(without "Args"). The former appears to be the correct name. I've seen a few of those and so have been assuming Args just gets added somewhere or whatever. 2. The naming for ECS Task Definitions appears to be ignored and so I opened a bug for that yesterday: https://github.com/pulumi/pulumi-aws-native/issues/619 3. And then this thing about errors with immutable fields that I'm trying to figure out (which I don't know if that's a Native problem or a me problem): https://pulumi-community.slack.com/archives/CRH5ENVDX/p1663090433029689?thread_ts=1663090433.029689&cid=CRH5ENVDX Is the issue tracker the best place to put things that I encounter and think might be bugs? Or is there a better place to discuss them and verify they're truly issues? Since this is brand new stuff I'm building, I'm happy to work off the cutting edge and help flush out issues, whatever's most helpful

Wrong docs are a bug - file and issue for those, and yes - GH issues are the right place. We have a triage process that should get those issues looked at (if not fixed) within a few days. I think that “invalid patch update” looks like a bug from afar. I think it should be triggering a recreate and it's not. (Possibly due to incorrect metadata upstream - not sure.)