dub: should we make it the de jure package manager for D?

[Wyatt]

Funny, I started this with a clear mindset, but it ended up more 
nuanced than I expected.

On Friday, 27 September 2013 at 13:43:59 UTC, Dicebot wrote:
>
> No, I mean that it does not make any difference between 
> "programs written in perl to be widely used" and "libraries / 
> tools for development in perl". For interpreted languages this 
> distinction hardly makes sense, but for natively compiled ones 
> it is pretty important.
>
That's true, though at some level I wonder if its continued 
prevalence more comes back to CPAN supporting system and 
local-to-user installation simultaneously.  Users have been 
adding ~/bin to their $PATH since $EPOCH.

> And that was kind of the core point of the argument - can 
> language-specific package manager be allowed to manage the 
> former?

Not at the system level, it probably shouldn't.  Ideally, binary 
executables and libraries are the exclusive demesne of the system 
package manager.

As a historical footnote, I suspect part of why CPAN works the 
way it does is it was designed and (I think) released before RPM 
was even written. (It may even predate the original dpkg.)  More 
important than long precedent, though: Perl is largely 
self-contained by default, and can be made completely so [0].

In some sense, I _like_ the idea of installing module source to 
e.g. /usr/lib64/d2/site_d/2.63/ as long as dub is built into a 
normal install (control env with a config file in ~) and let it 
update the user's dmd.conf as a value-add [1].

> I stand by the point that is a bad practice to provide any 
> functionality that allows it, Jacob has opposite point of view 
> :)

I... turns out I have mixed feelings on this.  In the general 
sense, I'm strongly inclined to agree with you.  External package 
management undermines the sysadmin's ability to make good package 
installation decisions, splits the system dependency graph, and 
can create file conflicts.

But on the other hand, as long as there are sufficient options 
(preferable), a utility, or an API to interrogate dub for 
complete useful metadata; I'll refrain from getting too vehement 
about it.  This is only because that means system package 
managers _can_ properly integrate it, should they choose to do 
so. (cf. g-cpan [2])

See, I have my standards as a sysadmin, but don't forget policy 
victims, either: many others are stuck dealing with a CErtaiN 
Terrible Old diStribution and would probably appreciate a tool 
that isn't stuck mired in Really HorriblE poLicy when they're 
trying to get work done. [3]

My breaking point is actually the idea of using dub to call the 
system package manager, which I still think is a Really Bad Idea. 
[4]

-Wyatt

[0] Consider the output of perl '-V:.*site.*' and the existence 
of Perlbrew (http://perlbrew.pl/)
[1] As a tangent, a nice separate utility to have might be 
something like a "dub-config" to help with module paths and maybe 
linkage (In the vein of all those /usr/bin/*-config things).  
Like so: dmd `dub-config --moddir vibed` thisLinksVibe.d.
[2] http://www.gentoo.org/proj/en/perl/g-cpan.xml
[3] Yes, juvenile RHELL potshots make me feel a little better 
about my situation.
[4] https://github.com/rejectedsoftware/dub/issues/52