Dub for internal dependency management: Git repo as package supplier?

[Guillaume Piolat]

On Wednesday, 31 July 2019 at 13:02:10 UTC, FeepingCreature wrote:
> We (Funkwerk) are currently using rake as a build system. Since 
> rake does not offer package management, we have to list all 
> transitive dependencies of every package, which is obviously 
> not satisfactory. Because of this, we're looking into switching 
> to dub and dub.selection.json as a "source of truth" for the 
> used set of library dependencies.
>
> We're currently using git submodules for local dependencies. If 
> they were migrated to dub, we'd run into the problem of what to 
> do while working on a dependency. Often changes to a dependency 
> only make sense in the context of the project that needs the 
> dependency, so we have to be able to set dub to use the git 
> branch that we're working on. However, while this can be made 
> to work locally by using dub add-override to point dub at a 
> folder that has the branch checked out, this cannot work on our 
> Jenkins system because obviously that doesn't have the local 
> folder.
>
> It seems to me that a possible solution would be to be able to 
> set a git repository as a dub package supplier. Dub would then 
> check out the repository to .dub/packages/<project>/<git hash>, 
> and build from there. dub.selections.json could store the 
> commit hash for reproducible builds.
>
> Since this would require a hefty amount of work on dub to 
> support git remote repos, I wanted to ask upfront: would such a 
> PR plausibly be accepted? And in case not, do you have 
> alternate proposals for D dependency management that won't 
> force us to tag a repo before using it in another project?
>
> Thanks for your consideration!

1.

You can use path-based dependencies, you won't have to listed 
dependencies transitively.
You _will_ have to:
- checkout everything, you can have several package in the same 
repo for example
- "your builds won't be reproducible" aka "you can't regress", 
because I don't think you can express versions with path-based
- dub.selections.json won't be effective for such path-based stuff


2.

I think you'd better host your own DUB registry