Python submodule import not found

[jsteinich]

🐛 Bug Report

Affected Languages

• TypeScript or Javascript
• Python
• Java
• .NET (C#, F#, ...)
• Go

General Information

• JSII Version: 1.39
• Platform: Windows 10. Python 3.8.5

What is the problem?

I'm doing some testing with cdktf version 0.6.4-pre.375. This includes a recent change to generate submodules for the aws provider. This works fine until runtime when the following error is produced:

Traceback (most recent call last):
      File "main.py", line 4, in <module>
        from imports.aws import AwsProvider
      File "C:\project\imports\aws\__init__.py", line 3869, in <module>
        import aws.access_analyzer
    ModuleNotFoundError: No module named 'aws'

The __init__.py file contains at the end a list of imports for all of the submodules. i.e. import aws.access_analyzer. This matches the behavior introduced with #3049. However, the aws module is being defined within that same file and doesn't seem to be referenceable at that point.

I manually updated the file with the imports replaced with a slightly different form: from ..aws import access_analyzer and everything seems to be running just fine.

Repro steps

1. Install latest cdktf (npm install -g cdktf-cli@next)
2. Clone https://github.com/hashicorp/terraform-cdk/tree/main/examples/python/aws
3. Populate cdktf.json terraformProviders with "aws@~> 3" (May also happen in v2)
4. Run cdktf get
5. Run cdktf synth and observe error

Other details

We've been having some issues reproducing this and similar issues in different environments. I haven't tracked down the source of difference yet, but I'm wondering if various python / virtualenv differences could be at play here.

[skorfmann]

I'll create a test repo to reproduce this on a small case. In a nutshell, this is causing issues for cdktf in scenarios where users are generating their own code bindings for a Terraform provider or module. The generated code ends up in user configured output directories, by default imports/aws/... for the AWS provider.

This is essentially a breaking change for existing Python users of the AWS provider (the only one with namespaces so far) in cdktf which are generating the code bindings themselves. For this reason, we locked jsii to 1.37.0 in our last release and can't upgrade to newer versions until we found a solution or at least a workaround.

One workaround which came to my mind is rather ugly: Configure jsii to output a imports.aws (where imports would be the user configured output directory) module and skip the generated imports folder when copying it to the final output folder. I'm curious if there are better ideas which are coming to your mind.

Side note: I'm assuming that's not an issue for us when generating packages, since it should be working similar to the aws-cdk-lib package. Gonna verify this, though.

[skorfmann]

Fixed with #3181

[NGL321]

Hmm, looks like this should have been autoclosed. Closing out now due to resolution.

If this is in error, please feel free to reopen

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.