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?

Reply via email to