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.
