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 checkone 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.