cdktf tries to use pipenv even tho I have removed it from cdktf.json

[trondhindenes]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

cdktf & Language Versions

❯ cdktf --version
0.14.1

Affected Resource(s)

Debug Output

Expected Behavior

cdktf should have executed poetry run python main.py, and never called pipenv

Actual Behavior

something inside cdktf calls "pipenv" even tho I've adjusted cdktf.json. Seems to me like it totally disregards the "app" attribute in the cdktf.json file

⠏  Synthesizing
[2022-11-18T18:54:22.986] [ERROR] default - Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project. You can set PIPENV_IGNORE_VIRTUALENVS=1 to force pipenv to ignore that environment and create its own instead. You can set PIPENV_VERBOSITY=-1 to suppress this warning.

Steps to Reproduce

Created a cdk tf app using the template.
Switched from pipenv to poetry.
Deleted Pipfile* Replaced app attr in cdktf.json with poetry run python main.py.
Verified that simply running poetry run python main.py works.
Tried running cdktf synth

This is the first time I'm looking at cdktf in about two years, and I'm quite certain I've used it with poetry before

Important Factoids

References

• #0000

[trondhindenes]

I just tested a bunch of different cdktf versions. Looks like this broke in [0.11.0](https://www.npmjs.com/package/cdktf-cli/v/0.11.0) 0.10.4 behaves as expected.

[trondhindenes]

Some more info on this: Only happens when cdktf.json has "sendCrashReports": "true"

[ansgarm]

Hi 👋
That is probably happening because the CDKTF CLI tries to determine the underlying version of the installed cdktf core Python package.

Is there a good way to spot that a Python project is using Python Poetry?

[trondhindenes]

Is there a good way to spot that a Python project is using Python Poetry?

yes:
if folder constains Pipfile --> assume its managed by pipenv
if folder contains poetry.lock --> assume it's managed by poetry

i would also add:
if command in cdktf.json app starts with poetry or pipenv that's also a strong indicator as to what command to run in order to grab package versions

[trondhindenes]

My cdktf.json looks like this, for instance:

{
  "language": "python",
  "app": "poetry run python main.py",
  "projectId": "490ecd27-404c-44cb-b2bc-1066ff1f28b3",
  "sendCrashReports": "false",
  "terraformProviders": [],
  "terraformModules": [],
  "codeMakerOutput": "imports",
  "context": {
    "excludeStackIdFromLogicalIds": "true",
    "allowSepCharsInLogicalIds": "true"
  }
}

when running "cdktf synth" cdktf will actually start the python process for me. So here the debug call should be poetry run pip freeze to list packages in the managed env. And pipenv run pip freeze if it were a pipenv-managed app.

[trondhindenes]

Just thinking more about this:
It might be neater to list packages programmatically instead of kicking off another process to do it:

try: from pip._internal.operations import freeze
except ImportError: # pip < 10.0
    from pip.operations import freeze

pkgs = freeze.freeze()
for pkg in pkgs: print(pkg)

That way cdktf doesn't have to care about which package manager is used

(provided of course that there are hooks in the python layer to add this kind of functionality - I wouldn't know anything about that)

[trondhindenes]

some more info while I'm at it:
A process wrapped in pipenv will always get the environment variable PIPENV_ACTIVE=1 set, so that's probably another safe
way to determine if pipenv is involved. But I guess you have to support both situations where users run pipenv run cdktf... and cdktf but the cdktf.json contains pipenv run python main.py so there are different ways to have cdktf and pipenv interact, and that's why I think this "assuming the world is perfect" that cdktf is doing now is so dangerous.

[giner]

Another more generic approach could be adding an option languageRuntimeCmd defaulting to pipenv run for python which could be redefined as poetry run or anything else user prefers.