I like dlang but i don't like dub

[Adam D Ruppe]

On Friday, 18 March 2022 at 18:16:51 UTC, Ali Çehreli wrote:
> As a long-time part of the D community, I am ashamed to admit 
> that I don't use dub. I am ashamed because there is no 
> particular reason, or my reasons may not be rational.


dub is legitimately awful. I only use it when forced to, and even 
making my libs available for others to use through it is quite an 
unnecessary hassle due to its bad design.

> That sounds great but aren't there common needs of those 
> modules to share code from common modules?

Some. My policy is:

1) Factor out shared things when I *must*, not just because I can.

So if it just coincidentally happens to be the same code, I'd 
actually rather copy/paste it than import it. Having a private 
copy can be a hassle - if a bug fix applies to both, I need to 
copy/paste it again - but it also has two major benefits: it 
keeps the build simple and it keeps the private implementation 
actually private. This means I'm not tempted to complicate the 
interface to support two slightly different use cases if the need 
arises; I have the freedom to edit it to customize for one use 
without worrying about breaking it for another.

When I must factor out it is usually because it is part of a 
shared public *interface* rather than an implementation detail. A 
shared interface happens when interoperability is required. The 
biggest example in my libs is the Color and MemoryImage objects, 
which are loaded from independent image format modules and then 
can be loaded into independent screen drawing or editing modules. 
Loading an image then being unable to display it without a type 
conversion* would be a bit silly, hence the shared type.

* Of course, sometimes you convert anyway. With .tupleof or 
getAsBytes or something, you can do agnostic conversions, but it 
is sometimes nice to just have `class SpecialImage { 
this(GenericImage) { } }` to do the conversions and that's where 
a shared third module comes in, so they can both `import 
genericimage;`.

2) Once I do decide to share something, there's a policy of tiers:

first tier has zero imports (exceptions made for druntime and 
SOMETIMES phobos, but i've been strict about phobos lately too). 
These try to be the majority of them, providing interop 
components and some encapsulated basic functionality. They can 
import other things but only if the user actually uses it. For 
example, dom.d has zero imports for basic functions. But if you 
ask it to load a non-utf8 file, or a file from the web, it will 
import arsd.characterencodings and/or arsd.http2 on-demand.

Basic functionality must just work, it allows those opt-in 
extensions though.

second tier has generally just one import, and it must be from 
the first tier or maybe a common C library. I make some 
exceptions to add an interop interface module too, but I really 
try to keep it to just one. These built on the interop components 
to provide some advanced functionality. This is where my 
`script.d` comes in, for example, extending `jsvar.d`'s basic 
functionality with a dynamic script capability.

I also consider `minigui.d` to be here, since it extends 
simpledisplay's basic drawing with a higher-level representation 
of widgets and controls, though since simpledisplay itself 
imports color.d now (it didn't when I first wrote them... making 
that change was something I really didn't want to do, but was 
forced to by practical considerations), minigui does have two 
imports... but still, I'm leaving it there.

Then, finally, there's the third tier, which I call the 
application/framework tier, which is the rarest one in my 
released code (but most common in my proprietary code, where I 
just `dmd -i` it and use whatever is convenient). At this point, 
I'll actually pull in whatever I want (from the arsd package, 
that is) so there is no limit on the number of imports. I still 
tend to minimize them, but won't take extraordinary effort. This 
is quite rare for me to do in a library module since this locks 
it out of use by any other library module! Obviously, no tier one 
or two files can import a tier three, so if I want to actually 
reuse anything in there, it must be factored out back to 
independence first.

C libraries btw are themselves also imports, so I also minimize 
them, but there's again some grey area: postgres.d use both 
database.d as the shared interface, but libpq as its 
implementation. I still consider it tier two though, despite a C 
library being even harder for the user to set up than 50 arsd 
modules.

3) I try to minimize and batch breaking changes, including breaks 
to the build instructions. When I changed simpledisplay to import 
color, it kinda bugged me since for a few years at that point, I 
told people they can just download it off my website and go.

I AM considering changing this policy slightly and moving more to 
tier two, so it is the majority instead of tier one. All my new 
instructions say "dmd -i" instead of "download the file" but I 
still am really iffy on if it is worth it. Merging the Uri 
structs and the event loops sounds nice, having the containers 
and exception helpers factored out would bring some real 
benefits, but I've had this zero-or-one import policy for so 
long, making it one-or-two seems too far. But I'll decide next 
year when the next breaking change release is scheduled.

(btw my last breaking change release was last summer and it 
actually broke almost nothing since i was able to migration path 
it to considerable joy. im guessing most my users never even 
noticed it happened)

> Despite such risks many projects just pull in code. (?) What am 
> I missing?

It is amazing how many pretty silly things are accepted as gospel.