DUB - call to arms

[Russel Winder]

On Sun, 2019-04-14 at 13:40 +0000, Adam D. Ruppe via Digitalmars-d
wrote:
> 
[…]
> No and no. Dub delivers negative value for my use-case; it is a 
> cost to me to maintain these definition files for other people 
> (and it is a support pain too, which people dropping in having 
> dub problems that don't exist in the underlying compiler), even 
> though I don't use it.

So that is fine, you do not use it. But for those who have experience
Cargo with Rust, Go, Conan with C++, etc. D needs something like Dub.

> I don't use it because it offers nothing of value to me; it 
> solves a problem I don't even have (and does so in a way that is 
> mostly incompatible with my existing code). It is all negative 
> with nothing in the positive column to balance it out.

See above. :-)

> 
> I'd say we split dub up into three concerns:
> 
> 1) code.dlang.org. I do see some value in this, and think it is 
> salvageable in its current form.
> 
> 2) dub, the package manager. Maybe useful, though I don't 
> personally believe in dependencies, I can see some value, though 
> I'd want to change it so it has more compatibility with other 
> workflows (like mine) and be sure to limit its scope to developer 
> use-cases; end users should never know.
> 
> 3) dub, the build tool. I'd rather have it either do absolutely 
> nothing here, or just delegate to something else.

I disagree. The lessons, particularly from Cargo/Rust, and Go is that
"small language, small standard library, large pool of trivially
accessible dependencies" is the way things are going just now. Having a
dependency and build manager is what Maven and (far better) Gradle have
been doing for yonks in the JVM-based milieu, this way of working is
finally penetrating into the native code arena.

Make, CMake, SCons, Meson, etc. remain tied to the "I have all the
source I need locally, everything else is provided via precompiled
static or dynamic libraries that are present locally". If this works
for a given use case fine. But increasingly the JVM world, Cargo/Rust,
Go are working with a distributed source code approach. An approach
that can use a central publishing place, local file locations, or
Git/Mercurial/Breezy repositories. 

Having worked with Gradle, Cargo, and Go, returning to the approach of
Make, CMake, SCons, and Meson really has no appeal to me at all.

A consequence of this for me is that for D almost all of Phobos should
not be in Phobos but should be in the Dub repository as packages, and
Dub should work with Git/Mercurial/Breezy repositories as easily as it
does with the Dub repostory and local filestores.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20190415/7c5b99fd/attachment.sig>