This message was deleted.

do you mean

runtime.options.virtualenv

specified in

Pulumi.yaml

?

Yeah, sorry, missed the

options

in the path.

and

./venv/bin/python --version

gives you Python 3.11.x?

Yes

I'm a little unclear what issue you're describing. Is it that when you're using

pip

, it's installing the wrong versions, or that pulumi isn't using the venv?

That's the same thing, or more precisely, the former is caused by the later.

pip

is a Python script which contains a shebang with path to the Python interpreter. When Pulumi is not using the

venv

,

pip

uses the wrong Python interpreter (on a system path)

so if you do

source .venv/bin/activate

(ie, use the venv in current shell), it all works. But without, pulumi defaults to using the system python env for running and installing. Can you post the contents of

Pulumi.yaml

, can redact anything sensitive?

so if you do

source .venv/bin/activate

(ie, use the venv in current shell), it all works.

Yes, exactly.

But without, pulumi defaults to using the system python env for running and installing.

That's not exactly what I stated (and hence the question). Pulumi clearly uses the

venv

for installing the dependencies and also interpreting the Pulumi program. It just doesn't switch to the virtualenv. (And thus, when using

local.Command

with command like

pip install ...

, it uses the

pip

on system path instead the one in the virtualenv.)

ok, I see. sorry, I hadn't picked up on that. This is likely a limitation as local.Command will be run from a different process. You'll need to activate the venv as part of the script you're running

Yeah, that's probably it, it didn't come to my mind that

local.Command

would most probably run the command in a subprocess... Thanks!

I think for the case of the Python runtime,

local.Command

should use the venv as well. It's worth raising a feature request. I've similar problems with passing Google Auth tokens around, and it'd be good to see functionality to remove this kind of boilerplate

Hi, I decided to not use

runtime.virtualenv

config at all because I've had multiple projects using the same VENV and just used

poetry shell

before I started working. Nevertheless, I also made a mistake of using pedantic for

pulumi.ComponentResource

which resulted in a lot of unnecessary type headaches with outputs. Apart from that I used ASDF to manage my python installations and sometimes Pulumi just did not register the PATH to python binary correctly 🤷 (perhaps it has to do something with multiple PyCharm windows I had opened) In the end, I decided to move to TypeScript because it is much easier to express and write for pulumi. Mainly due to required boilerplate of for python classes (this ma be a gamechanger though https://github.com/pulumi/pulumi/issues/11732) As for lambdas, I find your solution interesting. I settled on dissociating the artifact from pulumi and just give pulumi an S3 path of pre-built package, so that lambda can use any runtime and I can write a more generic/flexible component.