Skip to content

solver: relax rule to construct build unification sets - #51152

Merged
alalazo merged 2 commits into
spack:developfrom
alalazo:fixes/pythological-package-not-concretizing
Aug 25, 2025
Merged

alalazo merged 2 commits into
spack:developfrom
alalazo:fixes/pythological-package-not-concretizing

Conversation

@alalazo

@alalazo alalazo commented Aug 13, 2025 •

Copy link
Copy Markdown
Member

fixes #51134

Don't branch on "build" dependencies, but on "build"-only dependencies. This effectively reduces the number of nodes in the "generic_build" unification set, removing the ones that could be ("build", "run") or ("build", "link").

With this PR, spack/spack-packages#1078, and the following configuration:

concretizer:
  duplicates:
    max_dupes:
      py-jupyterlab: 2
      py-jupyter-packaging: 2
      py-jupyterlab-server: 2
      py-jupyter-server: 2

I can concretize py-geemap correctly.

I still need to figure out a good unit test, and whether this relaxation may cause issues in other edge cases.

Don't branch on "build" dependencies, but on "build"-only
dependencies. This effectively reduces the number of nodes
in the "generic_build" unification set, removing the ones
that could be ("build", "run") or ("build", "link").

Signed-off-by: Massimiliano Culpo <[email protected]>
@alalazo

alalazo commented Aug 13, 2025

Copy link
Copy Markdown
Member Author

@adamjstewart

@adamjstewart

Copy link
Copy Markdown
Member
concretizer:
  duplicates:
    max_dupes:
      py-jupyterlab: 2
      py-jupyter-packaging: 2
      py-jupyterlab-server: 2
      py-jupyter-server: 2

^ Should we make this the default? Could be a separate PR if you want.

Signed-off-by: Massimiliano Culpo <[email protected]>
@alalazo

alalazo commented Aug 13, 2025

Copy link
Copy Markdown
Member Author

Yeah, I need to think if this is the right choice, or if I just need to add more build tools 😞 We should make everything its own PR and time concretization, cause adding more nodes will probably slow it down.

@alalazo
alalazo marked this pull request as ready for review August 15, 2025 07:16
@alalazo alalazo added bugfix Something wasn't working, here's a fix v1.0.2 PRs to backport for v1.0.2 labels Aug 18, 2025
@haampie

haampie commented Aug 25, 2025

Copy link
Copy Markdown
Member
comparison

@alalazo
alalazo merged commit 5342f9f into spack:develop Aug 25, 2025
@alalazo
alalazo deleted the fixes/pythological-package-not-concretizing branch August 25, 2025 11:38
@adamjstewart

Copy link
Copy Markdown
Member
concretizer:
  duplicates:
    max_dupes:
      py-jupyterlab: 2
      py-jupyter-packaging: 2
      py-jupyterlab-server: 2
      py-jupyter-server: 2

^ @alalazo do you want to open a PR to add this too?

@alalazo

alalazo commented Aug 25, 2025 •

Copy link
Copy Markdown
Member Author

@adamjstewart Yeah, I'll do that and check how much it affects the concretizer. Maybe we should also start benchmarking concretization of ml specs.

@adamjstewart

Copy link
Copy Markdown
Member

This isn't used by any ML packages, only Jupyter packages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix Something wasn't working, here's a fix v1.0.2 PRs to backport for v1.0.2

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cannot concretize Jupyter ecosystem, multiple versions of build deps with incompatible run deps

3 participants