-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python is broken in jsii 1.2.0 when jsii modules are installed as submodules #1501
Comments
@RomainMuller I decided not to work around this in cdk8s because it creates a pretty convoluted hack, so we are pinning jsii to 1.1.0 in cdk8s until this is resolved. |
In jsii 1.2.0 the way python code loads jsii tarballs has been changed and is no longer "portable" in a sense that we can harvest the python code into a user-defined location in the cdk8s project (e.g. `imports`). Until this is fixed, we are pinning jsii to 1.1.0. jsii bug: aws/jsii#1501
In jsii 1.2.0 the way python code loads jsii tarballs has been changed and is no longer "portable" in a sense that we can harvest the python code into a user-defined location in the cdk8s project (e.g. `imports`). Until this is fixed, we are pinning jsii to 1.1.0. jsii bug: aws/jsii#1501
When a package is relocated from the root to within an arbitrary subpackage, the loading infrastructure fails to locate the .tgz file containing the JavaScript runtime for the library, because the original library name is hard-coded in the package. This removes the hardcoding and computes the modules' name from the `__name__` obtained at runtime. Additionally, moved the loading of the assembly within the `_jsii` subpackage, which makes the overall generated code ever so slightly cleaner. Fixes #1501
subpackage, the loading infrastructure fails to locate the .tgz file containing the JavaScript runtime for the library, because the original library name is hard-coded in the package. This removes the hardcoding and computes the modules' name from the `__name__` obtained at runtime. Additionally, moved the loading of the assembly within the `_jsii` subpackage, which makes the overall generated code ever so slightly cleaner. Fixes #1501
When a package is relocated from the root to within an arbitrary subpackage, the loading infrastructure fails to locate the .tgz file containing the JavaScript runtime for the library, because the original library name is hard-coded in the package. This removes the hardcoding and computes the modules' name from the `__name__` obtained at runtime. Additionally, moved the loading of the assembly within the `_jsii` subpackage, which makes the overall generated code ever so slightly cleaner. Fixes #1501
I'm having the same issue even with jsii 1.1.0. cdk8s 0.17.0 any hint @eladb ?
|
@iferca the generated import in your snippet looks like it was generated by jsii 1.2.0. Are you certain you are using cdk8s 0.17.0? |
@eladb from my Pipfie.lock:
|
Ok, I think I know what the issue is. The jsii dependency you care about is actually the dependency taken by the CLI, not by your app, and in 0.17.0 we declared the jsii dependency as a caret dependency. This means that if you installed the CLI after [email protected] was released, npm/yarn would take 1.2.0. We need to release a new cdk8s version with the pinned dependency in order to fix this. |
Okay, I've verified that indeed this is the case. Releasing cdk8s 0.18.0 which should include the pinned jsii version. Also, I believe that |
Okay, [email protected] has been released. If you reinstall your CLI ( |
[email protected] fixed the issue. Thank a lot |
@eladb as @jorgehrn mentioned, I can confirm that 0.18.0 can synth 👍 Thanks |
🐛 Bug Report
Affected Languages
Python
What is the problem?
cdk8s has an
import
command which uses jsii to generate python code on-demand and puts it in the user project underimports/<module>
.For example:
Will create a jsii python module under
$project_root/imports/k8s
which users then import via:When the cdk8s CLI is compiled with jsii 1.2.0, the generated python code will produce a module that cannot be imported this way and fails with the following error:
Analysis
The latest jsii submodules feature changed the calls to
JSIIAssembly.load
. Instead of passing__name__
it passes an jsii explicit module name instead (see PR comment).In the example above, this means that instead of
"imports.k8s"
it will pass only"k8s"
, and then the python loader will not be able to find the tarball resource (because there is no module namedk8s
).The text was updated successfully, but these errors were encountered: