My two cents

Laeeth Isharc laeeth at laeeth.com
Mon Oct 23 11:58:14 UTC 2017


On Friday, 20 October 2017 at 15:38:53 UTC, Martin Nowak wrote:
>> Commercial usage, shared libraries and stuff
>> There isn't any handy tool to download, manage and publish 
>> closed source stuff.
>> dub is great for simple solutions but useless in big projects 
>> with multiple targets, configurations, etc.
>> Everything is primary focused on opensource development (but 
>> everyone here wants to see D as a next successor of C++ in 
>> commercial sphere).
>
> Well, dub is a package manager to share code, so obviously OSS 
> it the main target. You can easily `dub add-local` packages or 
> run your private registry.


https://github.com/dlang/dub/pull/985
"A common use-case (that I currently have) is a large project 
with many dub packages in it, which much be registered with dub, 
but don't have any purpose outside that project. It also allows 
any dependencies to be easily packaged inside a project in order 
to allow building an application without an internet connection, 
by just running dub upgrade --root=$APP_PROJECT_DIR 
--defaultRepoPath=$PROJECT_ROOT/deps/ on the dev machine, then 
dub build --root=$APP_PROJECT_DIR 
--defaultRepoPath=$PROJECT_ROOT/deps/ --skip-registry=all on the 
target machine."

We've submitted a PR for our internal dub fork that we use to 
build a decent-sized project (not as big as Weka, but not much 
smaller).  Sadly it required quite a few changes and was hard to 
break into bite-sized ones.

If you're working on a big internal project, I'd say that it's 
worth thinking about things from a medium-term perspective.  With 
D you have higher costs to get the build system etc right, but 
you gain and keep gaining from having more concise, clearer, more 
maintainable, and more plastic code.  The costs are front-loaded 
though.  If one's able to take a medium-term perspective and the 
changes you want to see in dub are not all that much, it may well 
be worth finding someone in the D community you can pay to help 
make those changes.  A little money goes a long way because here 
you have strong programmers - who like programming! - from all 
over the world, and not everyone is in a situation that makes 
their opportunity cost as high as what it might be within the 
company (not just payroll, but overheads, co-ordination costs 
etc).

And you may find other commercial users are willing to split the 
costs - that's something a large media company asked me about, 
and that we would be open to also if it's something that will fit 
with what we need.

> And of course there are various other options like Make, CMake, 
> Meson, or Raggae.

(Reggae).  We use Reggae for building proprietary codebase.  If 
there's a feature missing, please do say - maybe we would benefit 
from it, and since Atila works with us, it's something easy to 
consider when time.


> As unfortunately with almost any OSS project, we're not that 
> many people, and each of us is investing a huge amount of time 
> into this.

Also - for example with dub.  Dub and vibe constitute an amazing 
achievement for one man.  I don't mean to diminish the 
contribution of others, but I guess Sonke has been the creative 
spirit behind them and has done most of the work.  There's one 
challenge that arises when you can benefit from the work of 
unusually productive people (of whom there seem to be many in the 
D community - I just take Sonke as one example), is that for that 
same reason they end up getting responsibility in the commercial 
parts of their lives, which might mean less time available to 
devote to open-source at certain points.

There are 39 pull requests open on dub currently. It's not a 
super-complicated code base, but I guess the people responsible 
for dub have quite a lot on their plates.  I don't know how 
others might be able to help, but maybe that is one area that 
would benefit the language ecosystem more generally.  (I get the 
impression sometimes that people want to help, but they don't 
completely know how).

There's no mention of dub here, for example:
https://wiki.dlang.org/Get_involved

Now there is.. (I just added it).
https://wiki.dlang.org/Get_involved#Review_pull_requests

> But again your best bet on getting sth. done is working on it, 
> be it writing a DIP, organizing the discussion, or actually 
> implementing it.

Bountysource went quiet, though I started contributing to it.  I 
wonder if there is a better way for commercial users to say what 
they might be willing to pay for and how much.  I don't think 
that keeping patches private for a while really fits.  It doesn't 
hurt me if some other D user benefits from work I sponsored.  In 
fact it helps me if it is incorporated into the main codebase, 
because that means I don't need to worry about maintaining it.  
And that's in any case way too selfish a perspective - not smart 
commercially: if D flourishes, it helps us too.


Laeeth.



More information about the Digitalmars-d mailing list