Vibemail - extensions for vibe's Mail class to send multi-part emails with attachments

[Sebastiaan Koppe via Digitalmars-d-announce]

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?