[gsoc] DUB - Ideas

[H. S. Teoh]

On Thu, Feb 28, 2019 at 12:45:56PM -0500, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> On 2/28/19 10:50 AM, Seb wrote:
> > @community: what features do you miss the most from DUB?
[...]
> Oh my...where to start...?
> 
> - Need a clear, obvious, dead-simple, 100% reliable way to tell DUB to
> keep its grubby hands out of my project's compilation. Tell it "Run
> this command to compile, run this other command to generate docs,
> etc., here's where you can find the resulting output, and otherwise,
> ***stay out of it!!***". Both the sdl/json config and the launched
> process should support appropriate envvars so I can cleanly
> pass-through CLI information like "Make docs instead of do build" or
> "use LDC" to my scripts without complicating them too much.

+1.


> - Need to be able to tell DUB "I want *THIS* compiler flag
> included/omitted", WITHOUT triggering a stupid big ugly warning, or
> having to manually translate the CLI flag into DUB-speak. Both GDC and
> LDC come with compatibility wrappers for DMD's CLI, so an additional
> abstraction layer here is neither necessary nor welcome.

+1.


> - Compile times that don't make a mockery of DMD.

+100.  I think dub has improved in this area the last time I checked,
but still, there's room for improvement.


> - DUB's default stdout output needs to STFU by default.

+1. Though to be fair, dub is already fairly quiet by defaut, compared
to some other programs that tend to get run during builds.


> - DUB and the compilers themselves should be bona-fide dependencies
> just like anything else.

+100.  I don't have a problem with special handling of certain types of
dependencies, but the user needs to be empowered to write the same
functionality without hacking dub's source code.  Empowerment before
convenience is my motto.


> - Needs good, solid support for non-source dependencies, system
> dependencies, and tools that the build itself depends on, not just
> libs your source depends on.

A generic dependency resolution system that the user can directly access
would address this point.


> - This following workflow needs to be a BASIC STANDARD FULLY-ROBUST
> use-case with the same priority and importance as running "dub" to
> build a project: I have a non-DUB project and I want to include a
> library (say, Vibe.D) via DUB. I have my CLI command(s) to invoke the
> compiler, and all I have to do to use Vibe.d (or whatever) is insert
> this as part of my compiler invocation:
> 
> dmd blah blah `dub include vibe-d:~0.8.3` blah blah
> 
> And boom, -I... paths, libs, Have_vibe_d, etc., all guaranteed
> working, correct and ready to go.
> 
> At one point, I did a lot of work to make that happen, and I made some
> progress, but it was just so contrary to the way dub wanted to work I
> finally gave up.
[...]

I tried doing a non-dub project with dub dependencies before, and ended
up with so much frustration that I threw in the towel and resorted to
the hack of creating an empty dummy dub project in a subdirectory, whose
sole purpose was to declare dub dependencies. I'd only run dub from the
subdirectory when one or more dependencies need to be updated, but the
actual compilation / linking is done by a different, sane build system
that pulls in the objects dub built.

The fact that such hacks are needed just to make dub work the way I want
it to, is a sign that something is fundamentally broken with its design.
Again, it's an issue of user empowerment, or lack thereof: in theory it
should be a tool that provides pluggable functionalities that the user
can integrate into whatever else he may be using.  Unfortunately, its
current design assumes the universe revolves around it, and requires
everything else to orbit around how it works. When that doesn't happen
it either works poorly, requiring contorted workarounds, or doesn't work
at all, needing to boxed off into its own sub-universe in which it's the
center of revolution before it is willing to play nice.  It's a hammer
that wields the user, rather than the other way round.  Most of the
above points are consequences of this fundamental point.


T

-- 
No! I'm not in denial!