[gsoc] DUB - Ideas

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Wed Mar 6 13:41:29 UTC 2019


On Wednesday, 6 March 2019 at 12:29:17 UTC, Seb wrote:
> Nope it only works locally. It does not work for anyone using 
> it via dub. As mentioned earlier, try fetching this package (or 
> any package with submodules) from the dub registry.

Yes.  But that's because you're doing something fundamentally 
inappropriate for the DUB package repo, which is to have source 
code dependencies defined somewhere (the git submodule system) 
that the DUB repo inherently cannot know about.

Basically if you want to have git submodules in the mix then you 
have to organize the entire dependency hierarchy for everything 
involved via git submodules rather than via the DUB package repo. 
  The git submodule issue isn't a blocker towards DUB being able 
to handle these dependencies, it's a blocker on the DUB package 
repo containing packages whose source code dependencies are not 
known to the DUB package repo.  Those are not quite the same 
things.

In other words, if you choose to bypass DUB's supply mechanisms 
and hand control to something else (like git), then you need to 
respect that separation of concerns: handle the supply via the 
tool you asked to provide supply, and just give DUB sufficient 
config to build the code once it has been supplied.

And it may be important to have that separation of concerns in 
your face -- after all, if it's trivial to just set a DUB package 
dependency to point at an arbitrary git repo, what's to stop me 
setting up a convenience library that depends on a git fork of 
vibe, which includes dodgy tracking components?

I trust that _your_ fork of vibe is well-motivated and only has 
bugfixes, but I'm not sure that I would trust that approach in 
general, and I am not so sure it's a good idea to open it up as a 
possibility in the DUB package repo.

After all, if you can't rely on upstream vibe to get out timely 
bugfix releases, maybe the problem is one of process rather than 
of DUB itself.  I'm not sure it isn't better to fix that process 
rather than open up a Pandora's box of dependency options to work 
around it.


More information about the Digitalmars-d mailing list