Support non-repo packages

[Abscissa]

Particularly for non-public libs/projects or projects needing a specific alternate fork of a dependency, DUB needs a way to specify a dependency on an arbitrary Git repo URL (Whether local, online, login-protected, etc.)

[s-ludwig]

DUBs approach is this:

git clone repo_url/project_name.git
dub add-local project_name ~master

This has the advantage that both, the exact repository URL, as well as the target path can be chosen. Especially the URL seems to be sensitive (e.g. different URL for public access and maybe per-user URLs for write access).

Coming to think of it, an alternative approach that works is to define the dependency in package.json like this:

{
    "dependencies": {
        "my-lib": {"version": "~master", "path": "../my-lib"}
    }
}

and then check out the project at ../my-lib.

[Abscissa]

The dub add-local does sounds like a good way (IIUC) to
locally-override the package origin given in package.json. But it
doesn't let you share a non-GitHub/non-BitBucket dependency as a
default part of the package description. You'd have to instruct users
to do the right "add-local".

I like the "path" thing in the json, as long as it works for both local
paths and general "http(s)://(...)blah.git" and "git://(...)blah.git"
stuff.

[s-ludwig]

You could also use a git sub-module and then use the "path" field in such situations (also solves pinning to certain revisions)... But extending "path" to take SCM URLs sounds like a good extension.

[deviator]

When you plain to implement this? dlibgit written for this issue?

[s-ludwig]

There is no fixed date/plan for this, yet. Next priority will be to get C language family build support. But this of course doesn't mean that someone else couldn't create a pull request.

An implementation of this should probably use the command line git tool rather than dlibgit, because libgit is available in different versions on different Linux distributions and different versions usually have incompatible APIs.

[dhasenan]

Another approach to this: add the repo as a git submodule, then add the path to the dependency in dub.json. This has the advantage that you can add different versions in different projects.

[dhasenan]

Yet another way to do this, if you have a sufficiently large organization: use a private dub registry. Considering there are at least three ways to accomplish this (dub add-local, submodules, private registries), do we need a fourth?

[wilzbach]

Considering there are at least three ways to accomplish this (dub add-local, submodules, private registries), do we need a fourth?

Yeah, "missing git support" is one of the top complaints about dub. Paths and submodules do okayish, but for example, submodules aren't currently fetched by DUB. This while being old, I think this issue is still valid today

[WebFreak001]

I think this would be really useful

[Geod24]

We now have the ability to depend on an SCM repository directly. We also have path dependencies, so I think that covers it.