Open alanraison opened 3 years ago
It seems that adding --mode=pinned
to the cdkdx upgrade-cdk
command would achieve this next time.
Lolz I've just seen that you're the cdkdx maintainer so you will know this! Sorry!
@alanraison Do you have an example where you had issues with the unpinned versions? I'm actually trying not to pin the versions. Others do that too: https://github.com/eladb/cdk-watchful
With cdk2.0 I planned to only use the stdlib as peerDependency. This makes dealing with dependencies much easier
It's just that whenever there's a new cdk version, this strategy forces us to update it straight away. I don't think this makes sense, especially as you are publishing updates whenever there's a cdk update anyway.
Ran into this exact issue. I'm running a project that requires cdk version 1.96.0 and 1.97.0 was just released. Running into this error trying to install cdk-constructs 1.33.0 (which should be fine for 1.96.0) but complains that cdk 1.97.0 is a requirement
$ pipenv install "cloudcomponents.cdk-cloudfront-authorization==1.33.0"
Installing cloudcomponents.cdk-cloudfront-authorization==1.33.0...
Adding cloudcomponents.cdk-cloudfront-authorization to Pipfile's [packages]...
✔ Installation Succeeded
Pipfile.lock not found, creating...
Locking [dev-packages] dependencies...
Building requirements...
Resolving dependencies...
✔ Success!
Locking [packages] dependencies...
Building requirements...
Resolving dependencies...
✘ Locking Failed!
[ResolutionFailure]: File "/usr/local/lib/python3.8/site-packages/pipenv/resolver.py", line 741, in _main
[ResolutionFailure]: resolve_packages(pre, clear, verbose, system, write, requirements_dir, packages, dev)
[ResolutionFailure]: File "/usr/local/lib/python3.8/site-packages/pipenv/resolver.py", line 702, in resolve_packages
[ResolutionFailure]: results, resolver = resolve(
[ResolutionFailure]: File "/usr/local/lib/python3.8/site-packages/pipenv/resolver.py", line 684, in resolve
[ResolutionFailure]: return resolve_deps(
[ResolutionFailure]: File "/usr/local/lib/python3.8/site-packages/pipenv/utils.py", line 1395, in resolve_deps
[ResolutionFailure]: results, hashes, markers_lookup, resolver, skipped = actually_resolve_deps(
[ResolutionFailure]: File "/usr/local/lib/python3.8/site-packages/pipenv/utils.py", line 1108, in actually_resolve_deps
[ResolutionFailure]: resolver.resolve()
[ResolutionFailure]: File "/usr/local/lib/python3.8/site-packages/pipenv/utils.py", line 833, in resolve
[ResolutionFailure]: raise ResolutionFailure(message=str(e))
[pipenv.exceptions.ResolutionFailure]: Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
First try clearing your dependency cache with $ pipenv lock --clear, then try the original command again.
Alternatively, you can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
ERROR: Could not find a version that matches aws-cdk.aws-cloudfront<2.0.0,==1.96.0,>=1.96.0,>=1.97.0 (from -r /var/folders/vf/1z_nkc1s5pz3s3v8f7nmxlq00000gp/T/pipenvof3oyh8wrequirements/pipenv-3mty8bjg-constraints.txt (line 5))
Tried: 0.26.0, 0.26.0, 0.27.0, 0.27.0, 0.28.0, 0.28.0, 0.29.0, 0.29.0, 0.30.0, 0.30.0, 0.31.0, 0.31.0, 0.32.0, 0.32.0, 0.33.0, 0.33.0, 0.34.0, 0.34.0, 0.35.0, 0.35.0, 0.36.0, 0.36.0, 0.36.1, 0.36.1, 0.36.2, 0.36.2, 0.37.0, 0.37.0, 0.38.0, 0.38.0, 0.39.0, 0.39.0, 1.0.0, 1.0.0, 1.1.0, 1.1.0, 1.2.0, 1.2.0, 1.3.0, 1.3.0, 1.4.0, 1.4.0, 1.5.0, 1.5.0, 1.6.0, 1.6.0, 1.6.1, 1.6.1, 1.7.0, 1.7.0, 1.8.0, 1.8.0, 1.9.0, 1.9.0, 1.10.0, 1.10.0, 1.10.1, 1.10.1, 1.11.0, 1.11.0, 1.12.0, 1.12.0, 1.13.0, 1.13.0, 1.13.1, 1.13.1, 1.14.0, 1.14.0, 1.15.0, 1.15.0, 1.16.0, 1.16.0, 1.16.1, 1.16.1, 1.16.2, 1.16.2, 1.16.3, 1.16.3, 1.17.0, 1.17.0, 1.17.1, 1.17.1, 1.18.0, 1.18.0, 1.19.0, 1.19.0, 1.20.0, 1.20.0, 1.21.0, 1.21.0, 1.21.1, 1.21.1, 1.22.0, 1.22.0, 1.23.0, 1.23.0, 1.24.0, 1.24.0, 1.25.0, 1.25.0, 1.26.0, 1.26.0, 1.27.0, 1.27.0, 1.28.0, 1.28.0, 1.29.0, 1.29.0, 1.30.0, 1.30.0, 1.31.0, 1.31.0, 1.32.0, 1.32.0, 1.32.1, 1.32.1, 1.32.2, 1.32.2, 1.33.0, 1.33.0, 1.33.1, 1.33.1, 1.34.0, 1.34.0, 1.34.1, 1.34.1, 1.35.0, 1.35.0, 1.36.0, 1.36.0, 1.36.1, 1.36.1, 1.37.0, 1.37.0, 1.38.0, 1.38.0, 1.39.0, 1.39.0, 1.40.0, 1.40.0, 1.41.0, 1.41.0, 1.42.0, 1.42.0, 1.42.1, 1.42.1, 1.43.0, 1.43.0, 1.44.0, 1.44.0, 1.45.0, 1.45.0, 1.46.0, 1.46.0, 1.47.0, 1.47.0, 1.47.1, 1.47.1, 1.48.0, 1.48.0, 1.49.0, 1.49.0, 1.49.1, 1.49.1, 1.50.0, 1.50.0, 1.51.0, 1.51.0, 1.52.0, 1.52.0, 1.53.0, 1.53.0, 1.54.0, 1.54.0, 1.55.0, 1.55.0, 1.56.0, 1.56.0, 1.57.0, 1.57.0, 1.58.0, 1.58.0, 1.59.0, 1.59.0, 1.60.0, 1.60.0, 1.61.0, 1.61.0, 1.61.1, 1.61.1, 1.62.0, 1.62.0, 1.63.0, 1.63.0, 1.64.0, 1.64.0, 1.64.1, 1.64.1, 1.65.0, 1.65.0, 1.66.0, 1.66.0, 1.67.0, 1.67.0, 1.68.0, 1.68.0, 1.69.0, 1.69.0, 1.70.0, 1.70.0, 1.71.0, 1.71.0, 1.72.0, 1.72.0, 1.73.0, 1.73.0, 1.74.0, 1.74.0, 1.75.0, 1.75.0, 1.76.0, 1.76.0, 1.77.0, 1.77.0, 1.78.0, 1.78.0, 1.79.0, 1.79.0, 1.80.0, 1.80.0, 1.81.0, 1.81.0, 1.82.0, 1.82.0, 1.83.0, 1.83.0, 1.84.0, 1.84.0, 1.85.0, 1.85.0, 1.86.0, 1.86.0, 1.87.0, 1.87.0, 1.87.1, 1.87.1, 1.88.0, 1.88.0, 1.89.0, 1.89.0, 1.90.0, 1.90.0, 1.90.1, 1.90.1, 1.91.0, 1.91.0, 1.92.0, 1.92.0, 1.93.0, 1.93.0, 1.94.0, 1.94.0, 1.94.1, 1.94.1, 1.95.0, 1.95.0, 1.95.1, 1.95.1, 1.95.2, 1.95.2, 1.96.0, 1.96.0, 1.97.0, 1.97.0
There are incompatible versions in the resolved dependencies:
aws-cdk.aws-cloudfront==1.96.0 (from -r /var/folders/vf/1z_nkc1s5pz3s3v8f7nmxlq00000gp/T/pipenvof3oyh8wrequirements/pipenv-3mty8bjg-constraints.txt (line 5))
aws-cdk.aws-cloudfront<2.0.0,>=1.96.0 (from cloudcomponents.cdk-cloudfront-authorization==1.33.0->-r /var/folders/vf/1z_nkc1s5pz3s3v8f7nmxlq00000gp/T/pipenvof3oyh8wrequirements/pipenv-3mty8bjg-constraints.txt (line 8))
aws-cdk.aws-cloudfront<2.0.0,>=1.97.0 (from cloudcomponents.cdk-lambda-at-edge-pattern==1.33.0->cloudcomponents.cdk-cloudfront-authorization==1.33.0->-r /var/folders/vf/1z_nkc1s5pz3s3v8f7nmxlq00000gp/T/pipenvof3oyh8wrequirements/pipenv-3mty8bjg-constraints.txt (line 8))
aws-cdk.aws-cloudfront==1.96.0 (from aws-cdk.aws-cloudfront-origins==1.96.0->-r /var/folders/vf/1z_nkc1s5pz3s3v8f7nmxlq00000gp/T/pipenvof3oyh8wrequirements/pipenv-3mty8bjg-constraints.txt (line 3))
aws-cdk.aws-cloudfront==1.96.0 (from aws-cdk.aws-route53-targets==1.96.0->-r /var/folders/vf/1z_nkc1s5pz3s3v8f7nmxlq00000gp/T/pipenvof3oyh8wrequirements/pipenv-3mty8bjg-constraints.txt (line 15))
aws-cdk.aws-cloudfront==1.96.0 (from aws-cdk.aws-s3-deployment==1.96.0->-r /var/folders/vf/1z_nkc1s5pz3s3v8f7nmxlq00000gp/T/pipenvof3oyh8wrequirements/pipenv-3mty8bjg-constraints.txt (line 2))
+1 for pinning versions.
Using @cloudcomponents/cdk-static-website
v 1.38.0. yarn install
failed with Node 14 (with lerna) when CDK v1.107.0 was released. Error was
error An unexpected error occurred: "expected hoisted manifest for \"@cash2web/infrastructure#@cloudcomponents/cdk-static-website#@aws-cdk/aws-s3-deployment#@aws-cdk/aws-lambda#@aws-cdk/aws-efs\"".
Fixed by using yarn resolutions to pin the version in package.json
like so:
...
"resolutions": {
"@aws-cdk/aws-cloudfront": "1.106.1",
"@aws-cdk/aws-iam": "1.106.1",
"@aws-cdk/aws-route53": "1.106.1",
"@aws-cdk/aws-route53-targets": "1.106.1",
"@aws-cdk/aws-s3": "1.106.1",
"@aws-cdk/aws-s3-deployment": "1.106.1",
"@aws-cdk/core": "1.106.1"
}
...
Since CDK versions often introduce changes, the versions of the CDK should be exactly specified in the package dependencies. This is how other CDK libraries (e.g. CDK Patterns https://github.com/cdk-patterns/serverless/blob/main/the-basic-mq/typescript/package.json) work.