Remotes do not work with rev tagged dependencies

[Smephite]

The remotes section does not work with rev tagged dependencies.

The following configurations work:

remotes:
    url: https://github.com/pulp-platform

dependencies:
  axi_obi:      { git: https://github.com/pulp-platform/axi_obi.git, rev: 205c9bb338df6955a0c4a300c5140d9ce413ec56 }

remotes:
    url: https://github.com/pulp-platform

dependencies:
  axi_obi:      { version: "0.1.0" }

But when trying to use a rev-tagged dependency without specifying the git field it does no longer work:

remotes:
    url: https://github.com/pulp-platform

dependencies:
  axi_obi:      { rev: 205c9bb338df6955a0c4a300c5140d9ce413ec56 } # Jun 18 2026

[DEBUG] canonicalized to "/scratch/kberszin/workspace/tmp"
[DEBUG] limit rdev = Some(66308)
[DEBUG] looking in "/scratch/kberszin/workspace/tmp"
[DEBUG] root dir "/scratch/kberszin/workspace/tmp"
[DEBUG] reading manifest "/scratch/kberszin/workspace/tmp/Bender.yml"
error: Error in manifest "/scratch/kberszin/workspace/tmp/Bender.yml".
 ├─› caused by: In dependency `axi_obi` of package `tmp`.
 ╰─› caused by: Invalid configuration for dependency `axi_obi`: (None, None, Some("205c9bb338df6955a0c4a300c5140d9ce413ec56"), None, None)

[fischeti]

This is actually intentional😉 The idea behind it is to nudge people into using versioned/tagged releases where bender can resolve version conflicts instead of branches/revisions. This way, the revision dependencies stand out more

[colluca]

While I understand the motivation behind this choice, and I agree that people should prefer versions over revisions, I disagree with the decision to limit the simplicity of use, versatility and intuitiveness of a tool or feature arbitrarily to influence user behaviour 😁

Simplicity of use

I think most people obviously prefer version tags over non-versioned revisions, but for practical reasons non-versioned revisions are nonetheless heavily used during development, oftentimes for extended periods of time until a feature is reviewed, merged, released, etc. Why force someone to go from:

  apb: 0.1.0

to:

  apb:
    git: https://github.com/pulp-platform/apb.git
    rev: dev

instead of simply going to:

  apb: dev

when naturally switching from a version to a development revision during development? Are we really forcing users to make more changes than necessary/intuitive to the Bender.yml as a reminder that they should create a new release after development? 😁

Versatility

Furthermore, there is the case of dependencies that are not versioned using the semantic versioning scheme, but perfectly valid (albeit surely less informative/feature-rich) versioning approaches (e.g. just using hashes on main). I understand Bender is primarily designed/optimized for semantically-versioned dependencies, but do we really want to arbitrarily limit its usefulness beyond this use-case?

Intuitiveness

I would also argue that the current distinction is counter-intuitive from a user perspective (as highlighted by this issue). If a remote just defines an alias to a Git repository URL, and if a single remote is automatically treated as the default, one would expect this to apply to Git dependencies in general, independent of whether the selector is version or rev.

Intuitively, the following should all be valid syntax:

remotes:
  pulp: https://github.com/pulp-platform

dependencies:
  apb: dev
  axi:
    remote: pulp
    rev: dev

If we want to nudge revision dependencies to be avoided, that should happen through warnings or some other mechanism, not by making the manifest syntax less regular.

Conclusion

People should be able to make the use they want of a tool, if it's reasonable. We shouldn't sacrifice simplicity of use, versatility and intuitiveness of a tool, to school them on how to maintain their repos.

[micprog]

Thanks for the detailed write-up @colluca. Two separate things are going on here: one is about what an identifier can promise, the other is a deliberate choice we'd defend.

What the short form means

A bare version is only meaningful relative to a source of versions. Every other dependency manager solves this with a registry — crates.io, npm, PyPI, the Go module proxy — so serde = "1.0" resolves because there is exactly one place to look, and because 1.0 means something there: an immutable, ordered, comparable artifact.

Bender has no registry. remotes is a stopgap for that: it lets a single Git userspace stand in for one, so <name> + <version> resolves by scanning the tags of <remote>/<name>.git.

Let me be clear about what the objection is not, though: it isn't that a revision can't be found. Branches are published exactly like tags, and resolving apb: dev against <remote>/apb.git would be straightforward to implement. The issue is what the two identifiers promise.

A version tag is immutable and carries compatibility information. 0.1.0 can be checked against ^0.1, so when two packages in a graph both depend on apb, the solver has something to work with. A branch is a moving pointer with no compatibility semantics — it means "whatever happens to be on dev when you look." Bender can pin that, but it cannot reason about it, and two dependents on two different revisions of the same package is simply unsatisfiable: there is no range to intersect.

So apb: 0.1.0 and apb: dev would sit in the same syntactic slot while behaving nothing alike — one is a constraint the solver can trade against, the other is an unconditional pin that quietly defeats resolution for everyone downstream. That collision is what we're avoiding, not a lookup problem.

It's also roughly the line other tools draw: Cargo rejects serde = { rev = "..." } without git; pip wants pkg @ git+https://...@dev; npm's short form still carries the repo path; Go encodes a commit as a pseudo-version under the full module path. The short form is reserved for identifiers with resolution semantics; pointers name their source.

And yes, the asymmetry is intentional

To be straightforward about it: @fischeti's answer was accurate, and I don't think the nudge is illegitimate. Bender.yml is not personal configuration — it's a published interface. A rev propagates transitively, and the cost of it isn't paid by the person who writes it; it's paid by whoever integrates your IP three levels down and has to work out why nothing resolves. That seems like exactly the case where it's reasonable for a tool not to make the option that externalises cost also the cheapest one to type.

Note what this does not do: nothing is blocked, no capability is lost, and the explicit form is one line —

apb: { git: https://github.com/pulp-platform/apb.git, rev: dev }

It also keeps revision dependencies greppable across the ecosystem, which is genuinely useful when auditing what's pinned to unreleased code.

On the non-semver case

Repositories versioned only by hashes on main can be depended on perfectly well today, via git + rev. What they can't do is participate in version resolution — not because bender forbids it, but because there is nothing there to resolve. Giving them registry-style syntax would advertise a capability that doesn't exist behind it.

Where you're right

(None, None, Some("205c9bb..."), None, None) is a terrible way to communicate any of the above, and I'd happily take a PR replacing it with something like: "dependency axi_obi specifies rev without git: revisions must name their repository explicitly." And warnings on revision dependencies aren't in tension with any of this — that's a reasonable addition on its own merits.

If and when there's a real registry, this distinction dissolves naturally and remote: + rev: becomes worth revisiting. Until then I'd rather not grow the surface of a mechanism we intend to replace.

[colluca]

Remotes as a registry surrogate

Summarizing the presumably AI-generated content, your argument seems to be:

The remotes feature is a surrogate for a missing registry. In a package registry dependencies would be uniquely tagged, and the tag would be used to source a package from the registry.

The way I see this, it basically means we are implicitly supporting three types of dependency sources (registry, git and path), and the first is the default. The others have to be explicitly labeled with a git or path key.

This makes sense.

Remotes as Git remote aliases

The documentation however says:

The remotes section allows you to define shorthand names for Git repositories. This makes the dependencies section much cleaner by avoiding repeated long URLs.

implying that remotes are actually just aliases for Git remote URLs, convenient to make the manifest more readable and less repetitive.

Proposal

The purpose of having a centralized registry is a separate discussion, but I assume it's useful. But, for the very reasons specified in the documentation, URL aliases are also useful. But there is no contradiction: these are logically orthogonal features, that can both be implemented.

Hence my proposal would be the following:

1. explicitly implement registry as a third type of source, despite a centralized registry doesn't exist yet (for the moment we're just using a collection of Git repos as a distributed registry)
2. the defaulting feature works only for registry-sourced dependencies
3. separately implement the aliasing feature

An example to clarify what I mean. Currently we have:

remotes:
  pulp: https://github.com/pulp-platform

dependencies:
  # Pattern 1 (legal)
  apb:
    version: 0.1.0

  # Pattern 2 (legal)
  apb: 0.1.0

  # Pattern 3 (legal)
  # Pattern 1 and 2 implicitly resolve to this, a Git-sourced (not registry-sourced) dependency:
  apb:
    git: https://github.com/pulp-platform
    version: 0.1.0

  # Pattern 4 (illegal)
  apb:
    rev: dev

  # Pattern 5 (illegal)
  apb: dev

My proposal would be:

# Remotes are Git remote aliases.
# Temporarily, the same can be used also as a specification for the surrogate distributed registry or...
remotes:
  pulp: https://github.com/pulp-platform

# ... we can use a dedicated snippet (unnecessary for now IMO, but could be used in the future)
registry:
  pulp: https://github.com/pulp-platform

dependencies:
  # Pattern 2 (still legal, same as before)
  apb: 0.1.0

  # Pattern 2 resolves to this now, an explicit, registry-sourced (not Git-sourced) dependency
  apb:
    registry: 0.1.0

  # Pattern 1 (now illegal)
  apb:
    version: 0.1.0

  # Pattern 1 has no explicit source tag (`git`, `path`, `registry`) thus implicitly resolves to this (illegal, registry does not accept other keys)
  apb:
    registry: None
    version: 0.1.0

  # Pattern 4 (still illegal)
  apb:
    rev: dev

  # Pattern 4 has no explicit source tag (`git`, `path`, `registry`) thus implicitly resolves to:
  apb:
    # Illegal, unspecified tag
    registry: None
    # Illegal, registry does not accept other keys
    rev: dev

  # Pattern 5 (illegal)
  apb: dev

  # Pattern 5 implicitly resolves to:
  apb:
     # Illegal, can't source from registry with a revision
     registry: dev

  # Pattern 6 (legal, serves the aliasing purpose described in current Bender docs)
  apb:
    git: pulp
    rev: dev

  # Pattern 7 (aliases to Pattern 3, legal, albeit redundant but not equal to Pattern 2)
  apb:
    git: pulp
    version: 0.1.0

To be honest I think this could also still be improved, but better to discuss this in person as it would otherwise just take too long.

The other argument

A rev propagates transitively, and the cost of it isn't paid by the person who writes it; it's paid by whoever integrates your IP three levels down and has to work out why nothing resolves. That seems like exactly the case where it's reasonable for a tool not to make the option that externalises cost also the cheapest one to type.

That makes sense. But I was referring to use during development. A user is not expected to use an IP that is under development, unless they know what they're doing, so it isn't about passing the cost onto a user, it's just about convenience during development.

[fischeti]

The documentation however says:

The remotes section allows you to define shorthand names for Git repositories. This makes the dependencies section much cleaner by avoiding repeated long URLs.

implying that remotes are actually just aliases for Git remote URLs, convenient to make the manifest more readable and less repetitive.

Yes, I think the documentation could be more clear here.

The whole registry thing is likely never going to happen, even though this would be a more optimal way to do it. This is why we tried to at least give the impression that there is a registry but in the form of github/gitlab group(s). And a registry would never accept revisions like branches since they are not persistent. If you upload something to a registry, you should not change it anymore since people might depend on it. Branches get force-pushed all the time or even deleted once merged and you don't have a guarantee as a downstream user, whether the revision will exist in the future. A Similar problem exists when specifying commit hashes. Even though they point to a fixed snapshot, they can be orphaned if they are not tracked anymore by a branch/tag and eventually the git garbagge collecter might/will completely wipe them. This is pretty bad when you are doing a tapeout and one year later when the chip comes back, you cannot access the dependencies anymore. Bender even has functionalities to retrieve orphaned commits, and emit a warning but it cannot save you from the fact that those commits might be deleted upstream forever at some point.

Tags solve this problem, since they point to fixed commits, and the commits they track are persistent. We could argue that we could allow default remotes for git tags, if you want to pick up a workflow based on that. But then again, if you want to reference git tags, you could also pick up semantic versioning which would solve the entire problem.

You could argue that using default branches like main or devel are a bit better since they are less prone to history changes. However, default branches are just a convention not a strict rule (is it devel or develop or dev or ...), and git itself does have no notion about it at all so bender does not have a way of knowing whether a branch refers to a default branch or not.

This is why we want to push people a bit into making proper release with semantic versioning. Whether this is on a registry or on Github is in the end secondary. Working on branches should only be a temporary measure and making them stand out in the bender manifest is one way to do it (if you have any other ways on how to enforce this better let me know🤓). And as @micprog said, revisions are not limited in any way. They are just a bit more verbose to type in the manifest.

A rev propagates transitively, and the cost of it isn't paid by the person who writes it; it's paid by whoever integrates your IP three levels down and has to work out why nothing resolves. That seems like exactly the case where it's reasonable for a tool not to make the option that externalises cost also the cheapest one to type.

That makes sense. But I was referring to use during development. A user is not expected to use an IP that is under development, unless they know what they're doing, so it isn't about passing the cost onto a user, it's just about convenience during development.

The development never ends😉 Also how does one know whether an IP is under development or not?