One patched package source. Like RegistryPackageSource,
the loader stitches the supplied (name, version, manifest_path) into the graph; unlike a registry entry, the
resulting WorkspacePackage is tagged kind = PackageKind::Local
because the user pointed Cabin at a local working copy. The
orchestration layer in cabin filters the regular
registry list so a patched name’s only entry comes from
patches.
One foundation-port package source. Built by the CLI
orchestration layer after cabin_port::prepare() materializes
the port directory; the loader resolves a
DependencySource::Port declaration to the matching entry
here and inserts a WorkspacePackage tagged
kind = PackageKind::Local (foundation ports are local
development policy and never enter published metadata).
One registry package source that has already been fetched and
extracted by cabin-artifact. cabin-workspace accepts these
pre-resolved entries via load_workspace_with_options so it can
fold them into the package graph alongside local packages.
How the loader treats a versioned dependency edge whose name is
not present in registry. Pre-resolution loads (port discovery,
cabin metadata fallback) carry no registry yet but may carry
patches that contribute names to the loader’s internal name map;
the RegistryPolicy::StrictFor variant lets callers scope
enforcement so the resolver-less paths don’t surface bogus
missing-registry diagnostics.
Load a workspace or a single package starting from the given manifest
Path. Workspace members and local path dependencies are resolved
recursively against the filesystem; a topologically-sorted
PackageGraph is returned.
Load the workspace with a single options bag. When
include_dev_for is empty the loader follows the
cabin build policy of treating dev-deps as
declaration-only; with a non-empty set, listed packages
contribute their [dev-dependencies] as real graph edges
(path-deps are materialized, version-deps reach the
resolver). Dev-deps still don’t propagate transitively —
only the listed packages activate them.