mod provides

module provides

Virtual candidates generated from EasyBuild exts_list entries.

A scientific-Python bundle lists its array library in exts_list. The solver must treat that as a provide: a requirement for that library at a given version is satisfied by selecting the parent bundle, rather than by inventing a standalone module for it easyconfig. The same rule applies to Python-bundle-PyPI and R-bundle-CRAN.

Expansion is idempotent. Synthetic candidates are marked by crate::domain::Candidate::EXT_PROVIDE_MARKER in easyconfig_path and depend on the parent bundle at its exact version.

Variables

const EXT_PROVIDE_MARKER: &str

Marker embedded in easyconfig_path for a virtual extension provide.

Functions

fn aliased_module_name(name: &str) -> String

The module name an alias maps a foreign name to, or the name unchanged.

overlay_package_identity answers “are these the same package”, which is a normalised key and not something to write into a recipe: the identity of poetry-core is poetrycore, and no module is called that.

fn existing_language_provider<'a>(name: &str, candidates: &'a [Candidate]) -> Option<&'a Candidate>

Bundle or first-class module in candidates that already ships name.

Prefers an exts_list parent (the bundle that ships the package) over a same-named first-class recipe.

fn expand_extension_provides(candidates: &[Candidate]) -> Vec<Candidate>

Add one virtual candidate per exts_list entry that is not already present.

Existing first-class recipes with the same name remain; Resolvo chooses. Entries with an empty name or version are skipped. Candidates that are already provides are not expanded again.

fn extension_parent_path(path: &str) -> Option<&str>

Parent easyconfig path of a synthetic provide, when path is one.

fn ignored_build_requirement(name: &str) -> bool

Whether a stated build requirement should stay out of the emitted recipe.

A Python project names the language and its array library among its build requirements; neither is an EasyBuild build dependency of an overlay, since the stack supplies both.

fn is_python_marker_crate(name: &str) -> bool

Whether depending on this crate means the crate builds a Python extension.

fn overlay_package_identity(name: &str) -> String

Identity used when matching a PyPI/CRAN name to a robot module or exts_list provide, so a package known by two names collapses to one.

fn path_is_extension_provide(path: &str) -> bool

True when path names a synthetic extension provide.

fn python_module_for_crate(crate_name: &str) -> Option<String>

The Python module a PyO3 crate imports as, when it differs from the crate name.

fn refuses_pip_overlay(name: &str) -> bool

True when --format pypi must not emit a PythonBundle overlay.

These are toolchain-built extensions. A pip wheel on top of EESSI (or any EasyBuild scientific Python) is the wrong install.

fn resolve_extension_provider<'a>(selected: &'a Candidate, selected_set: &'a [Candidate]) -> &'a Candidate

Collapse a selected extension provide to its parent bundle candidate.

fn shipped_with_python(name: &str) -> bool

Whether the EasyBuild Python module already ships this package.

EasyBuild builds setuptools, pip and wheel into Python itself, so a project that states one as a requirement already has it once it depends on Python. Emitting a dependency instead sends the solver looking for anything that ships the name, and what it finds can be an unrelated application that happens to carry it as an extension.