python: unable to synth pre-existing `App` for `cdktf` > 0.10

[b-c-lucas]

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

Core

• python: 3.9.13
• cdktf: 0.12.1

Deps

• constructs: 10.1.85
• jsii: 1.65.0

Affected Resource(s)

Not exactly sure what this means.

The error is stemming from core cdktf class App.

Debug Output

Traceback (most recent call last):
  <redacted>
  File "/var/task/<redacted>.py", line 67, in synth
    app = App(outdir=str(tmp_dir))
  File "/opt/python/jsii/_runtime.py", line 86, in __call__
    inst = super().__call__(*args, **kwargs)
  File "/opt/python/cdktf/__init__.py", line 33, in __init__
    def __init__(self,*,context=None,outdir=None,skip_validation=None,stack_traces=None):options=AppOptions(context=context,outdir=outdir,skip_validation=skip_validation,stack_traces=stack_traces);jsii.create(self.__class__,self,[options])
  File "/opt/python/cdktf/__init__.py", line 65, in __init__
    if __debug__:type_hints=typing.get_type_hints(AppOptions.__init__);check_type(argname='argument context',value=context,expected_type=type_hints['context']);check_type(argname='argument outdir',value=outdir,expected_type=type_hints['outdir']);check_type(argname='argument skip_validation',value=skip_validation,expected_type=type_hints['skip_validation']);check_type(argname='argument stack_traces',value=stack_traces,expected_type=type_hints['stack_traces'])
KeyError: 'context'

Expected Behavior

Existing CDKTF stack synths app as for previous cdktf version (0.10.4).

Actual Behavior

Exception raised due to something typing-related.

Steps to Reproduce

Important Factoids

References

• I know there was a similar issue in one of aws-cdk/jsii/constructs, but don't know which issue (let me dig that up).

[DanielMSchmidt]

Can you check what the App construct has as inputs? It looks to me like something incorrect is passed into the context key of the App.

[b-c-lucas]

Can you check what the App construct has as inputs? It looks to me like something incorrect is passed into the context key of the App.

The line of python that builds the App construct is as follows, with tmp_dir being a pathlib.Path:

app = App(outdir=str(tmp_dir))

The context parameter has a default value of None, though we've had it working this way for almost a year now and seems to be expected according to the examples docs.

To your point, though, I would agree that it does seem like something related to the context param changed between 0.10.4 and 0.12.

[b-c-lucas]

I believe this is the change that AWS CDK used to work around a similar issue: https://github.com/aws/aws-cdk/commit/ab3bb710b29a1d243eed4ee3f6527685fe8d9ac4

Looks like jsii-pacmak has been fixed accordingly, with aws-cdk now using ^1.65.0.

[b-c-lucas]

Looks like cdktf 0.12.2 was released since I logged this issue, and looks to have a similar package.json setup as our working aws-cdk dep.

Will give it a shot and see what happens.

[b-c-lucas]

Looks like cdktf 0.12.2 was released since I logged this issue, and looks to have a similar package.json setup as our working aws-cdk dep.

Will give it a shot and see what happens.

I think this issue might be fixed inherently by the package updates taken in 0.12.2, as I'm now getting a different error.

[ERROR] AttributeError: module 'cdktf' has no attribute 'ISSHProvisionerConnection'

That being said, I can't say it's fully working since I'm stuck on an old version of azurerm and I can't tell if the cdktf version is simply happening earlier in the call chain.

If someone can get a new version of cdktf-cdktf-provider-azurerm live, I'd be happy to test it out and hopefully close the issue.

[dzdiscoveryzone]

Looks like cdktf 0.12.2 was released since I logged this issue, and looks to have a similar package.json setup as our working aws-cdk dep. Will give it a shot and see what happens.

I think this issue might be fixed inherently by the package updates taken in 0.12.2, as I'm now getting a different error.

[ERROR] AttributeError: module 'cdktf' has no attribute 'ISSHProvisionerConnection'

That being said, I can't say it's fully working since I'm stuck on an old version of azurerm and I can't tell if the cdktf version is simply happening earlier in the call chain.

If someone can get a new version of cdktf-cdktf-provider-azurerm live, I'd be happy to test it out and hopefully close the issue.

I'm getting the same error. Judging by the errors, I would imagine once the azurerm provider is updated for cdktf it might resolve this issue. I'm running cdktf 0.12.2 with cdktf-cdktf-provider-azurerm version 2.0.10 (released august 3rd)

[ansgarm]

Hi 👋 I'm on this and currently waiting for this upstream PR to be merged in Projen, so that we can configure our Github Actions to run with more memory which in turn will allow us to build and release updated pre-built provider packages for providers like Azurerm (and a few others).

Usually Projen is quire quick in merging and releasing PRs but if that takes longer, I'll switch to a fork in the meantime to unblock this.

[ansgarm]

Everything seems to have rolled out successfully 🚀

cdktf-cdktf-provider-azurerm v2.0.11 has been released to PyPI 🐍

[dzdiscoveryzone]

Everything seems to have rolled out successfully 🚀

cdktf-cdktf-provider-azurerm v2.0.11 has been released to PyPI 🐍

Thank you @ansgarm this resolved my issues!

[b-c-lucas]

Everything seems to have rolled out successfully 🚀

cdktf-cdktf-provider-azurerm v2.0.11 has been released to PyPI 🐍

Testing this out now; thanks for the quick turnaround (especially on getting us caught up for the azurerm provider). I'm excited that @dzdiscoveryzone is fixed up, so hopefully I'll report back with good news.

[b-c-lucas]

Testing this out now; thanks for the quick turnaround (especially on getting us caught up for the azurerm provider). I'm excited that @dzdiscoveryzone is fixed up, so hopefully I'll report back with good news.

I gave this a shot the other day, hoping I could wrap this up before my on-call rotation at work, but upgrading to the latest azurerm (+ azuread) did not fix my issues deploying the existing CDKTF app.

I'm kind of stuck between a rock and a hard place on this one: I've got deadlines that will likely prevent me from being able to allocate time toward this until late October.

Thank you @ansgarm this resolved my issues!

@dzdiscoveryzone - would you mind sharing the versions of related pypi deps you're using for getting yours working? That might help me at least figure out what's different in our usages.

[dzdiscoveryzone]

Testing this out now; thanks for the quick turnaround (especially on getting us caught up for the azurerm provider). I'm excited that @dzdiscoveryzone is fixed up, so hopefully I'll report back with good news.

I gave this a shot the other day, hoping I could wrap this up before my on-call rotation at work, but upgrading to the latest azurerm (+ azuread) did not fix my issues deploying the existing CDKTF app.

I'm kind of stuck between a rock and a hard place on this one: I've got deadlines that will likely prevent me from being able to allocate time toward this until late October.

Thank you @ansgarm this resolved my issues!

@dzdiscoveryzone - would you mind sharing the versions of related pypi deps you're using for getting yours working? That might help me at least figure out what's different in our usages.

Sorry to hear you're still having issues, I wonder if some of that is due to the azuread provider which I currently am not using. Here's my Pipfile below:

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[requires]
python_version = "3"

[packages]
cdktf = "~=0.12.2"
pytest = "*"
cdktf-cdktf-provider-azurerm = "~=2.0.11"
cdktf-cdktf-provider-databricks = "~=2.0.45"

[ansgarm]

@brad-lucas when trying out the latest versions of azurerm and azuread: Did you try them with CDKTF v0.12.2 or 0.12.1?

[b-c-lucas]

@brad-lucas when trying out the latest versions of azurerm and azuread: Did you try them with CDKTF v0.12.2 or 0.12.1?

yes, though the "different error" I ran into was also using 0.12.2, so I'm unsure what happened underneath. I was kind of wondering if I need a specific version of jsii, constructs, or something else that I might need to pin in my package setup.

The particular install I'm debugging was only explicitly using:

• cdktf==0.12.2
• cdktf-cdktf-provider-azuread==2.0.42
• cdktf-cdktf-provider-azurerm==2.0.11

I kicked off a mini debug session this morning which blew away any local changes to jsii and constructs deps, but I actually though the projen bug might have still lingered for the azuread package, so I'm going to try out the latest and greatest of our 3 main package deps to see what I end up with.

What gets installed using latest cdktf + azuread and azurerm providers:

• attrs==22.1.0
• cattrs==22.1.0
• cdktf==0.12.2
• cdktf-cdktf-provider-azuread==2.0.46
• cdktf-cdktf-provider-azurerm==2.0.12
• constructs==10.1.94
• exceptiongroup==1.0.0rc9
• jsii==1.66.0
• publication==0.0.3
• python-dateutil==2.8.2
• six==1.16.0
• typeguard==2.13.3
• typing-extensions==4.3.0

[github-actions[bot]]

Hi there! 👋 We haven't heard from you in 30 days and would like to know if the problem has been resolved or if you still need help. If we don't hear from you before then, I'll auto-close this issue in 30 days.

[b-c-lucas]

Finally had a chance to pick this back up; same thing. :(

• cdktf==0.14.1
• cdktf-cdktf-provider-azuread==4.0.0
• cdktf-cdktf-provider-azurerm==4.0.1
• constructs==10.1.176
• jsii==1.71.0

Traceback (most recent call last):
...
File "/var/task/<***REDACTED***>.py", line 68, in synth
  app = App(outdir=str(tmp_dir))
File "/opt/python/jsii/_runtime.py", line 109, in __call__
  inst = super().__call__(*args, **kwargs)
File "/opt/python/cdktf/__init__.py", line 33, in __init__
  def __init__(self,*,context=None,outdir=None,skip_validation=None,stack_traces=None):options=AppOptions(context=context,outdir=outdir,skip_validation=skip_validation,stack_traces=stack_traces);jsii.create(self.__class__,self,[options])
File "/opt/python/cdktf/__init__.py", line 65, in __init__
  if __debug__:type_hints=typing.get_type_hints(AppOptions.__init__);check_type(argname='argument context',value=context,expected_type=type_hints['context']);check_type(argname='argument outdir',value=outdir,expected_type=type_hints['outdir']);check_type(argname='argument skip_validation',value=skip_validation,expected_type=type_hints['skip_validation']);check_type(argname='argument stack_traces',value=stack_traces,expected_type=type_hints['stack_traces'])
KeyError: 'context'

The code has been minified, but that line should still "work"... no idea why __debug__ is being evaluated as truthy, though.

[b-c-lucas]

After a long time coming, this comes down to a bug in our minification logic, not the code itself. 🤦

Safe to close this out.

[ansgarm]

Oh, wow! Glad you found it 🎉

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.