Mars Drafting Library - Official community driven library

[ZombineDev via Digitalmars-d]

I like the idea of having an additional library that we would 
ship alongside Phobos with every release. There of course some 
obvious pros and cons for having 'Mars' (or whatever is called) 
as a DUB packages vs included in the standard library:

Pros for being a DUB package:
+ faster release cycles (push a new version any time).
+ semantic versioning (instead of dmd 2.0xx).
+ can depend on other DUB packages (doesn't need to include 
everything it uses beside Phobos, ofc).
+ can have different configurations / build types, be split in 
DUB subpackages and all the other nice things that the DUB 
package format provides.
+ can include other binaries (eg. C libs).
+ etc...
Cons:
- Probably not so well tested, because it won't get as wildly 
used as Phobos.
- Third-party with zero guarantees. (You have to trust the 
author(s) that it is not malicious or anything like that).
- Not everybody is comfortable with having DUB as a dependency on 
their project.
- Can be a bit of an inconvenience if you only want to write a 
small script.
- DUB doesn't have first class support in the major IDEs, AFAIK 
(for people that prefer them over the terminal). Actually I thing 
it's extremely simple to use on the command-ling and I have no 
problem with Mono-D or "dub generate visuald", but it's not like 
the NuGet support in VS for .NET projects (AFAIR you can now have 
language plugins/analyzers based on Roslyn (linting, DSLs, etc.) 
which are NuGet packages that you download from their gallery).
- etc...

Pros being included alongside Phobos:
+ Better testing because more people can/will use it
+ Potentially better code, because of code review during pull 
requests and generally high standards for new stuff (like with 
std.experimental.logger).
+ More stable, because people may care more for backwards 
comparability (though the points is that this will not be 
guaranteed).
+ People new to the language will feel more comfortable using 
'standard' libraries.
+ etc...
Cons:
- Extremely slow release cycle.
- Hard to get new stuff (controversial like GUI) in.
- Not being able to have external dependencies than druntime and 
Phobos (like bindings for C libraries)
- etc...

With all that said I still think that it is a good idea to have 
another library shipping alongside Phobos with every DMD release 
(or GDC, LDC, etc.).
I think a good compromise would be the following:

1. Include DUB with DMD. We don't need a stable DUB as a library 
API to just use it to get other packages.
2. Make 'Mars' a DUB package and use semantic versioning to tag 
new releases.
3. Move it to github.com/D-Programming-Language/.
4. Include last known 'well working' with every DMD release. (Of 
course other implementations are free to decide whether to 
include it). Or we can have some post-installation script which 
would call DUB.
5. Afterwards if a new version of 'Mars' is released users can 
just do a 'dub upgrade' to update the one that's already 
included, or wait for a new official release.

I really do thing that this would be a step in the right 
direction. For example Microsoft has been been using their 
package manager NuGet "as a .NET Framework release vehicle" quite 
successfully for the last couple of years. Here[1] you can see 
that they are providing quite large and heavily used parts of 
.NET.

Another good idea is to separate Phobos from DMD and also put it 
on DUB. As you can see[2] many of the integral parts of.NET are 
provided as packages and people have no problem using them as 
such (you can see by the large download numbers).


[1]: http://blogs.msdn.com/b/dotnet/p/nugetpackages.aspx
[2]: https://www.nuget.org/packages