presence of dynamic packages leads to linking error during `leeway exec`

[geropl]

Bug description

leeway exec cannot find the dynamic package install/preview:docker (when it is building the dependency tree?) and fails with:

gitpod /workspace/gitpod/components/server (gpl/12758-list-plans) $ yarn watch
yarn run v1.22.19
$ leeway exec --package .:app --transitive-dependencies --filter-type yarn --components --parallel -- yarn build -w --preserveWatchOutput
FATA[0000] cannot load workspace                         error="linking error in package components:all: package \"install/preview:docker\" is unknown"
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Steps to reproduce

• open https://gitpod.io/#https://github.com/gitpod-io/gitpod/commit/1516e4c4dfdfbf54660b60860d80fb37aa840a1c
• cd components/server
• yarn watch

Expected behavior

It should execute yarn builds instead

Example repository

No response

Anything else?

No response

[csweichel]

This is actually caused by the "dynamic existence" of installer/preview:docker. It only exists when the right arguments are passed at linking stage.

Options:

Make components:all dynamic.

Doesn't require a leeway change, but significantly increases the complexity of our build set up because we have to duplicate conditions.

Add optional dependencies which are ignored if they're not present

For example (notice the ?) at the end:

deps:
  - installer/preview:docker?

[mads-hartmann]

This is actually caused by the "dynamic existence" of installer/preview:docker. It only exists when the right arguments are passed at linking stage

In the dynamic component (here) I had ensured that I created a package with the same name in either case as an attempt to avoid this situation. So I thought that there might be a bug in Leeway where dynamic components weren't evaluated in all conditions. I tried to make a minimal example here but I haven't been able to reproduce the bug yet.

[csweichel]

This is actually caused by the "dynamic existence" of installer/preview:docker. It only exists when the right arguments are passed at linking stage

In the dynamic component (here) I had ensured that I created a package with the same name in either case as an attempt to avoid this situation.

That's smart!
Actually in that case I'd prefer not to merge #103, just to not add this complexity needlessly.

So I thought that there might be a bug in Leeway where dynamic components weren't evaluated in all conditions. I tried to make a minimal example here but I haven't been able to reproduce the bug yet.

I just tried to reproduce using the steps described by Gero. I have not been able to reproduce this either.

Random thought: this might be some odd dependency on the order of a map. Just thinking that because that's the only thing introducing non-determinism in the linking process.