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
