Should this work?

[Marco Leise]

Am Thu, 09 Jan 2014 23:32:37 +0000
schrieb "Brad Anderson" <eco at gnuk.net>:

> On Thursday, 9 January 2014 at 20:40:30 UTC, H. S. Teoh wrote:
> > On Thu, Jan 09, 2014 at 09:19:40PM +0100, Jacob Carlborg wrote:
> >> On 2014-01-09 17:35, Marco Leise wrote:
> >> 
> >> >I Phobos should follow OpenGL in this regard and use a
> >> >prefix like `etc` for useful but not finalized modules, so
> >> >early adapters can try out new modules compare them with any
> >> >existing API in Phobos where applicable (e.g. streams,
> >> >json, ...) and report any issues. I have a feeling that right
> >> >now most modules are tested by 2 people prior to the merge,
> >> >because they spent a life in obscurity.
> >> 
> >> That has been suggested before and the counter argument is that
> >> people will start using and complain when it's changed, even 
> >> if it's
> >> in an experimental. Someone here said that the javax. packages
> >> originally was experimental packages to they continued to live 
> >> in
> >> the javax namespace to avoid breaking changes.
> > [...]
> >
> > Maybe instead of calling it 'etc' we should outright call it
> > 'experimental'. If you have code like:
> >
> > 	import experimental.myawesomemodule;
> > 	...
> >
> > I doubt you'd object very much when you have to rename it to:
> >
> > 	import std.myawesomemodule;
> > 	...
> >
> > since the word 'experimental' staring you in the face every 
> > time you
> > open up the file will be a constant nagging reminder that you're
> > depending on something unstable, giving you motivation to want 
> > to move
> > it to something stable as soon as you can.
> >
> >
> > T
> 
> I was of the opinion that phobos needed an experimental section 
> for getting real world testing of proposed modules but these days 
> I think we should just stick things up on dub (including modules 
> proposed for inclusion in phobos).

Dub is a nice extension to D, but it falls way to short for
what I expect package management to do on Linux:

o system wide installation of shared libraries
o keep one library per ABI, where ABI is a cross of:
  (x86,amd64) x (dmd,ldc,gdc) x (compiler version)
o therefore accept custom library installation paths
o remove packages that weren't explicitly requested and are
  not a dependency of something else

Actually I don't expect dub to do all that. It duplicates
parts of the existing package manager, which has to be used to
seamlessly integrate with the rest of the system anyway.
Dub does make building foreign packages a snap and that's what
it is great for, but soon people will expect complete
applications with their dependencies to be in the package
list. At least as soon as someone writes something _popular_
in D that uses more than just DMD. (This excludes vibe.d for
example, which is - I think - the most notable D product
outside of this community.)

-- 
Marco