I am curious how we can support other remotes in the future for URLs that need to be resolved like this.

Maybe bpkg_solve_uri could look for a user space function that can format a pathspec like this...

thinking out loud:

# in ~/.bpkgrc

bpkg_resolve_uri_pathspec () {
  # ...
}

in the bpkg_solve_uri function we could do:

bpkg_solve_uri() {
  if test -f bpkg_resolve_uri_pathspec; then
    bpkg_resolve_uri_pathspec $@
    return $?
  fi

  # ... rest of implementation
}

Maybe using some configuration instead of code. Let's say that in $HOME/.bpkg/urlmap file with one regex that on matching gives the URI to be used. @jwerle Maybe your proposal fits better in bpkg. Just let me know

https://gitlab*:$user/$name/-/raw/$version
https://github*:$user/$name/$version

I started looking into adding this feature a while back. Essentially providing configurable repository sites. The default would be GitHub, but we could add additional. The bpkg.json could have a section for repositories to provide project specific dependencies.

On top of that, bpkg.sh provides a collection JSON and that would be a default, but others could setup their own (ie: internal teams and projects). Collections (as they are now) could be updated to get the latest project repositories. Subsequent project/system installs would use this list first, unless a dependency is specified with a FQDN.

I'm going to look into this PR further and provide additional feedback.

It's OK to use ShellSpec for testing? Following #133

Added external URL resolve tested with ShellSpec. Test execution : shellspec --shell /bin/bash

Nit: I think something like this is more readable and removes the shellcheck warning:

if [[ $(type -t bpkg_resolve_uri_pathspec) == function ]]; then
	bpkg_resolve_uri_pathspec "$@" || bpkg_resolve_uri_default "$@"
else
	bpkg_resolve_uri_default "$@"
fi

It preserves the behavior where if bpkg_resolve_uri_pathspec fails, we then use our bpkg_resolve_uri_default function to resolve the uri (i think it's easy to miss that detail). But, should this be considered a bug? If I define a bpkg_resolve_uri_pathspec myself, I expect it to be the only function used to resolve URI, even if my function returns with a non-exit code. It might be better to keep the "string" blank as-is, or to print an error instead.

the idea behind bpkg_resolve_uri_pathspec its not to be the only solver but a complimentary one to help everyone else solve their problem and stil let the heavy lifting to bpkg

About the code suggestion is a very good one. I take it

Fixed at be225d1

Thanks for the update; I do still think that both bpkg_resolve_uri_pathspec and bpkg_resolve_uri_default shouldn't be invoked in the same codepath sequentially like that. I would be interested in hearing the other maintainers weigh in, but in any case, I'm not trying to stop this code from being merged as-is - it's a smaller detail.