Skip to content
DocumentationDependencies & toolchains
On this page

Page resources

Open Markdownllms.txtView source

Last updated

One makes external packages and language tools part of the same exact, per-root supply chain as semantic packages and implementation claims. A checked-in ecosystem manifest is not required for a One-native project.

Put compatibility policy in one.one

The project declaration is the canonical place for root-wide dependency and toolchain constraints. Resolver namespaces are ordinary imported packages, not built-in package-manager keywords:

one 1

semantic parcelhub
    domain one.project@1
    use one.dependency.cargo@1
    use one.dependency.npm@1
    use one.dependency.pypi@1
    use one.build.toolchain.rust@1
    use one.build.toolchain.node@1
    use one.build.toolchain.python@1

    project ParcelHub@1
        source ./one/product.one
        source ./one/implementations.one

        dependencies
            cargo.serde = 1
            npm.react = 19
            npm."@opentelemetry/api" = 1
            pypi.httpx = >=0.27,<1

        toolchains
            rust = 2024
            node = 24
            python = >=3.13,<3.14

        lock ./one.lock

The right side is an ecosystem-owned compatibility constraint, not an exact release. Names containing ecosystem punctuation use a quoted package segment. Roles, Cargo features, Python extras, targets, optionality, and other qualifiers remain explicit and keep the meaning defined by their resolver.

Constraints do not create dependency edges

A project entry constrains the whole root but is inert until an implementation actually needs the package. Its source-language analyzer derives demands from imports, macros, plugins, native links, tests, generated interfaces, assets, and target requirements.

Use an implementation-local entry only when analysis cannot derive the edge, when its role or feature must be stated, or when the implementation requires a narrower constraint:

impl parcelhub.orders#OrdersRust@1
    realizes parcelhub.orders#Orders@1
    using one.language.rust#OwnedAsync@1
    config
        edition = 2024
        warnings = deny
    dependencies
        cargo.serde
        cargo.tokio = >=1.40,<2
            feature macros
            feature rt-multi-thread
        cargo.proptest
            role test
    toolchains
        rust = 2024
    source
        // ordinary Rust body

An entry without = uses the applicable project and published-package constraint. A local constraint may narrow project policy but cannot widen it. One intersects project policy, published requirements, local constraints, and derived demand. A contradiction reports every contributing source instead of choosing a winner.

Resolve one atomic lock

one sync
one check

one sync proposes the complete exact solution and commits it only after review. one.lock retains releases, checksums, signatures, provenance, features or extras, targets, consumer edges, transitive edges, toolchains, resolver revisions, and qualifications as one atomic root. one update proposes newer compatible selections against an exact registry observation.

Checks, builds, tests, editors, and language servers never update the lock as a side effect. A typo offers reviewable candidates and never downloads a similarly named package silently. one bundle creates or imports the exact dependency, tool, and trust closure for offline work.

Build in private ecosystem workspaces

Build projects the selected closure into a private receipted Cargo, npm, PyPI, or peer workspace. Generated Cargo.toml, lockfiles, package.json, or pyproject.toml files are disposable tool inputs, not a second authoring surface. Their fields navigate back to the exact source demand, resolver rule, lock edge, and Build projection receipt.

Physical sharing follows the ecosystem's actual rules: Cargo features unify only inside one composed Cargo artifact graph, npm may retain nested versions, and Python uses the selected environment's version solution. Deduplicated bytes grant no reachability to another implementation.

Brownfield manifests may be adopted as exact inputs. After a project adopts the One-native path, source and one.lock become the only mutable dependency control plane; the imported manifest does not remain a parallel authority.

See project and workspace and supply chain.