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?
