Python dependency versions not handled correctly #676
Assignees
Labels
Comments
garnaat
added
bug
garnaat
pushed a commit
to garnaat/jsii
that referenced
this issue
Aug 5, 2019
…requires section of setup.py. Fixes aws#676.
MrArnoldPalmer
added a commit
to MrArnoldPalmer/jsii
that referenced
this issue
Nov 28, 2019
Change logic of python dependency version ranges. Parse semver number either as specific version or range and output to setup.py. Fix aws#676
5 tasks
MrArnoldPalmer
added a commit
to MrArnoldPalmer/jsii
that referenced
this issue
Dec 11, 2019
Change logic of python dependency version ranges. Parse semver number either as specific version or range and output to setup.py. Fix aws#676
MrArnoldPalmer
added a commit
to MrArnoldPalmer/jsii
that referenced
this issue
Dec 11, 2019
Change logic of python dependency version ranges. Parse semver number either as specific version or range and output to setup.py. Fix aws#676
MrArnoldPalmer
added a commit
to MrArnoldPalmer/jsii
that referenced
this issue
Dec 11, 2019
Change logic of python dependency version ranges. Parse semver number either as specific version or range and output to setup.py. Fix aws#676
MrArnoldPalmer
added a commit
to MrArnoldPalmer/jsii
that referenced
this issue
Dec 11, 2019
Change logic of python dependency version ranges. Parse semver number either as specific version or range and output to setup.py. Fix aws#676
MrArnoldPalmer
added a commit
to MrArnoldPalmer/jsii
that referenced
this issue
Dec 12, 2019
Change logic of python dependency version ranges. Parse semver number either as specific version or range and output to setup.py. Fix aws#676
MrArnoldPalmer
added a commit
to MrArnoldPalmer/jsii
that referenced
this issue
Dec 13, 2019
Change logic of python dependency version ranges. Parse semver number either as specific version or range and output to setup.py. Fix aws#676
RomainMuller
added a commit
that referenced
this issue
Dec 18, 2019
The dependency statements generated in the Java, .NET and Python packages generated by `jsii-pacmak` were not reflecting the dependency statement modeled on the source package. In certain pathological cases, such as Python, the dependency declaration was often more permissive than what the source package allowed, resulting in surprising behavior as well as difficult to troubleshoot problems. This updates several elements involved in this problem: 1. The `jsii` compiler no longer carries declarations of the entire (transitive) dependency closure of the package into the `.jsii` file. Instead, only direct dependencies are represented. This is fine because `jsii` already demands that all assembliesof which a type is re-exported be declared (at least) as a `peerDependency`, and the change also ensures that `peerDependency` declarations are considered in the same way that regular `dependencies` are. 2. The version statements in the `dependencies` section of the `.jsii` file no longer contains the "compile-time resolved" version number, but the actual SemVer expression declared in the package's source. 3. `jsii-pacmak` renders the declared SemVer range in the relevant form for the target being generated. Fixes #676 Related to #1137
RomainMuller
added a commit
that referenced
this issue
Dec 18, 2019
The dependency statements generated in the Java, .NET and Python packages generated by `jsii-pacmak` were not reflecting the dependency statement modeled on the source package. In certain pathological cases, such as Python, the dependency declaration was often more permissive than what the source package allowed, resulting in surprising behavior as well as difficult to troubleshoot problems. This updates several elements involved in this problem: 1. The `jsii` compiler no longer carries version information for transitive dependencies of the assembly in the `dependencyClosure` property, and instead only carries the `targets` configuration for those. 2. The version statements in the `dependencies` section of the `.jsii` file no longer contains the "compile-time resolved" version number, but the actual SemVer expression declared in the package's source. Also, the `targets` object was dropped (only the SemVer range statement remains), as this incurred needless duplication of the target configuration (in `dependencies` and `dependencyClosure`). 3. `jsii-pacmak` renders the declared SemVer range in the relevant form for the target being generated. Fixes #676 Related to #1137
RomainMuller
added a commit
that referenced
this issue
Dec 19, 2019
The dependency statements generated in the Java, .NET and Python packages generated by `jsii-pacmak` were not reflecting the dependency statement modeled on the source package. In certain pathological cases, such as Python, the dependency declaration was often more permissive than what the source package allowed, resulting in surprising behavior as well as difficult to troubleshoot problems. This updates several elements involved in this problem: 1. The `jsii` compiler no longer carries version information for transitive dependencies of the assembly in the `dependencyClosure` property, and instead only carries the `targets` configuration for those. 2. The version statements in the `dependencies` section of the `.jsii` file no longer contains the "compile-time resolved" version number, but the actual SemVer expression declared in the package's source. Also, the `targets` object was dropped (only the SemVer range statement remains), as this incurred needless duplication of the target configuration (in `dependencies` and `dependencyClosure`). 3. `jsii-pacmak` renders the declared SemVer range in the relevant form for the target being generated. Fixes #676 Related to #1137
mergify bot
added a commit
that referenced
this issue
Dec 27, 2019
…m module (#1141) * fix(pacmak): generated dependencies are arbitrary The dependency statements generated in the Java, .NET and Python packages generated by `jsii-pacmak` were not reflecting the dependency statement modeled on the source package. In certain pathological cases, such as Python, the dependency declaration was often more permissive than what the source package allowed, resulting in surprising behavior as well as difficult to troubleshoot problems. This updates several elements involved in this problem: 1. The `jsii` compiler no longer carries version information for transitive dependencies of the assembly in the `dependencyClosure` property, and instead only carries the `targets` configuration for those. 2. The version statements in the `dependencies` section of the `.jsii` file no longer contains the "compile-time resolved" version number, but the actual SemVer expression declared in the package's source. Also, the `targets` object was dropped (only the SemVer range statement remains), as this incurred needless duplication of the target configuration (in `dependencies` and `dependencyClosure`). 3. `jsii-pacmak` renders the declared SemVer range in the relevant form for the target being generated. Fixes #676 Related to #1137 * pr review feedback actions * add missing file Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
🐛 Bug Report
Affected Languages
TypeScriptorJavascriptPythonJavaC#,F#, ...)General Information
What is the problem?
Transitive dependencies are not handled correctly in Python. If you install version 1.2.0 (for example) of a CDK module, any transitive dependencies pull in the latest version and you get an incompatible set of modules. This issue has also been reported in CDK as aws/aws-cdk#3517
Verbose Log
The text was updated successfully, but these errors were encountered: