On Tuesday, 29 September 2015 at 16:22:43 UTC, Adam D. Ruppe wrote:
>> I copy/pasted your arsd/dom.d code in a couple of projects. But none of them will receive updates unless I do 'm manually.
>
> That means you don't have to put up with me randomly breaking your code! You don't have to wait for me to publish a bug fix. You aren't locked in to the way I did things and are free to customize it as you wish.

But this encourage to create tiny little forks everywhere. So everyone is getting less bugfixes: if I have my local copy, nothing encourages me to contribute the fix.

This is the strength of versionned dependencies:

- one master tree

- get bugfixes automatically before you are aware they even exist

- do not close the door to breaking changes in the form of a major version bump.

- open/closed principle for packages: if you use devisualization:window, the X11 package is pulled and linked without anymore work. This sub-dependency doesn't leak into your project, it's only a property of the primary dependency you used.

So I'd DUB strive to make dependencies composable, where they were previously a leaky abstraction. It's like calling a function and not having to know what it does inside.

Of course this implies there is no bad-fixes or SemVer misuse :) But I've found this to work reasonably well in practice.

On Tuesday, 29 September 2015 at 16:22:43 UTC, Adam D. Ruppe wrote:
> But, how do you express the half-dependency of characterencodings in a dub.json dependencies list?

optional dependencies + version tags produced by DUB in the form of

    version (Have_packagename)
    {

    }


(never tried)

On Tuesday, 29 September 2015 at 16:22:43 UTC, Adam D. Ruppe wrote:
>
> characterencodings is only needed if you call one of the character conversion functions; it is a lazy local import inside a template.

Neat! I knew local imports were useful for keeping symbols in a smaller scope, but didn't think about it as a way to control dependencies.

Sorry for the late reply. Had some stuff to finish.

On Tuesday, 29 September 2015 at 16:22:43 UTC, Adam D. Ruppe wrote:
> dub forces me to do it that way. It isn't my preference, but reorganizing all my files and creating twenty or thirty different github repos to house them is unacceptable.

Well, the current situation is unacceptable either. Imagine everyone did it like that. It would be a long list of 'misc' on code.dlang.org. No way to find anything.

> The unit of encapsulation in D is the module. If a module does two wildly different and independent things, you would break it up. Similarly, and I think this is often neglected, if two modules are intertwined and one cannot work without the other, they are really one unit and should be merged.

True. What do you think about cases which have a layered approach? Example:

Layer 1: bindings to some c lib
Layer 2: D wrappers
Layer 3: high-level functions

Now if someone doesn't like my high-level functions, at least they can just implement something on top of layer 2.

I am wondering because I am considering something like this for my upcoming upnp library.

> D's modules work! Why does dub reject this model?

Probably because of version control.

> There needs to be a balance struck between "don't repeat yourself" and avoiding dependencies.

I am reminded of yosefk's article: http://yosefk.com/blog/redundancy-vs-dependencies-which-is-worse.html

His attitude is to avoid dependencies as the plaque, sometimes at the cost of copy-paste.

> It is generally considered a bad idea to do the whole system together at once. (though Docker and VMWare appliances and such do actually try to do that and have found some success in the market) Making changes to that means a lot of extra work that is easy to do wrong. (The duplication itself btw isn't a big problem to me, computers are good at doing the same thing over and over again; it is an easily automated problem, at least until something goes wrong.)

Before Docker I would always make readme's describing what dependencies to install, what versions, etc. Ofcourse I would be too lazy to write the thing in the first place, or too lazy to update it. Or I would just forget to do it.

At least with Docker that no longer happens. Everything is right there, in a standard format.

In my last project we had 4 micro-services supporting our mobile app, each one only has an `app.d` file with less than 800 loc, most of which is just copy-pasted between them.

I have to say I really liked the experience compared to having an monolith app.

And yes, each micro-service has its own repo, and each has 2 dependencies: vibe.d and one specific to the service.

>> I copy/pasted your arsd/dom.d code in a couple of projects. But none of them will receive updates unless I do 'm manually.
>
> That means you don't have to put up with me randomly breaking your code!

Sure those are good benefits, but you can't expect a whole community to work like that.

Besides, what if it was a crypto package and you just fixed some flaw. Obviously you want to push that change. At least dub will tell me `there is a newer version`.

>> However, the idea of having a package-manager is a good idea. If only to serve as documentation on the libs you package depends on.
>
> But, how do you express the half-dependency of characterencodings in a dub.json dependencies list?

I suppose the answer is: it either depends on it, or it doesn't.

How do other systems handle this?