Oh, it could also be that.

in fairness, I think this is only a warning -- the

go get

actually succeeds

I’d have expected that to show up in CI though?

Yes, it does build

We use vendoring and

dep ensure

. It appears these warnings only fire for

go get

and not for

go build

/

go install

.

I would be tempted to adjust the build instructions however - it would be better if the instructions were to clone the repo into GOPATH and then run

dep ensure

rather than to use

go get

In this section: https://github.com/pulumi/pulumi/blob/master/README.md#building-from-source

Definitely. Not sure why we seem to be of two minds there. I'll make sure we get this sorted out.

Thanks for catching this!

I’m fairly sure

go get

will do the wrong thing with respect to dependencies absent of

vendor/

being checked in

The "Building and Testing" instructions immediately thereafter are a better representation of what we do in CI and in our own dev workflow.

Yes, that seems to work better.

I’ll open a PR to fix the

moby

import anyway

Thank you!

#1558 should fix it.

Hello - I'm just starting out with Pulumi and using Python... though I'm by no means a Python developer. I have a question about debugging. What is the recommended debugging approach? When I step into my function (the aws-python template to start with), I get a "RunError Pulumi program not connected to the engine -- are you running with the

pulumi

CLI?" Is there an article I haven't found yet which talks about how to run in a debugger with the engine connected?

Does this page exist somewhere still? It is referenced in

<http://common.mk|common.mk>

if you don’t have Python configured (I’ve never touched Python on a fresh OS X install), but the page 404s. I had search in the docs and can’t find anything related but could easily be missing something. https://github.com/pulumi/home/wiki/Package-Management-Prerequisites

(Sorry for all the questions, trying to get up to speed for contributions)

On the positive side, I have Python27 installed and am able to run the example, including some of my own minor edits. Pulumi looks like it will be very powerful for combining solution and infrastructure definition is one place! Looking forward to doing more with it!

Would it make sense to have language specific channels in Slack?

@square-gigabyte-16212 Pulumi programs are executed when you run

pulumi update

and

pulumi preview

- but in general they will not make sense to run directly with

python

or

node

CLIs. The programs themselves register resources with a pulumi engine that understands how to turn those resources into operations against your target cloud. See https://pulumi.io/reference/how.html for some details on this process. As you've noted though, that does though mean you can't use existing debuggers directly, because

pulumi

will spawn python on your behalf. I'm sure we'll be able to add support for passing through flags to allow attaching a debugger to the spawned process, but it's possible we don't have a first class way to do that today. If you open an issue on this, we can take a look at what options might work already today, and what new support might make sense to add to allow debuggers to easily light up.

Hi @white-balloon-205 - thanks for your reply and clarifying the current state of dev tools. I'll try to put together my thoughts into a github issue as you suggest. I feel like there are 2 angles... 1 is basic debugging of the pulumi program while 2 is debugging functions that might be ultimately running serverless (e.g. AWS Lambda) but are complex enough to require local debugging and/or unit tests. I suppose there might be a recommended software design/architecture which decomposes at certain boundaries to enable the local debugging/unit testing, and then have the Lambda simply call into the appropriate component to pass the "event" for handling. I might be rambling now, but I think I'm seeing how the needed debugging might be doable today using this decomposition approach.

Note we do have this related issue: https://github.com/pulumi/pulumi/issues/1372

Ahh - yes - I was referring to debugging the deployment code (though honestly it hasn't in general been that common to need to debug those programs as when there are issues the failure modes tend to make clear whats going on). For debugging runtime callback code - that is indeed a more interesting and common case. Today, the answer is generally to use existing tools for diagnosing issues in serverless function or containers - logging, IOPipe, AWS XRay, etc. Though unfortunately, the state of the art in this space isn't particularly great. We do offer a simple

pulumi logs

command that provides an easy way to see logs from all the sources of compute in your application.

Thank you for great product. We are starting to implement it for our clients and internal projects. I would love to contribute to your OpenSource part. Is it of use for anybody here if pulumi preview would be able to generate UML diagrams of the infrastructure?

Petr, welcome, and I'm so happy that you're excited by Pulumi! We are a big fan of visualizing resources around here, and actually have a DOT file generator built into the CLI: https://pulumi.io/reference/cli/pulumi_stack_graph.html. Our plan is to have a "Graph" tab in the service UI eventually that would show you a nice visualization using D3 of this. Not quite UML, but we've found it to be helpful. If you come up with something, we'd love to see it and better understand what's useful in practice.

The templates page linked from the UI 404s: https://pulumi.io/tour/basics-templates.html

@stocky-spoon-28903 uploaded a file: