Vision for the first semester of 2016

[Márcio Martins via Digitalmars-d-announce]

On Wednesday, 3 February 2016 at 05:41:52 UTC, Tofu Ninja wrote:
> On Wednesday, 3 February 2016 at 03:19:57 UTC, earthfront wrote:
>> On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe 
>> wrote:
>>> When you do `import std.string;` you expect it to just work, 
>>> and you find std.string's docs easily from dmd.
>>>
>>> I'd love it if you could do `import thirdparty.independent;` 
>>> and it magically works too - without even need for a 
>>> configuration file or an install command. And the docs are 
>>> right there and tutorials are written however the author 
>>> feels like writing them.
>>
>> OMG I would love this.
>> Often I write short scripts and use rdmd for rapid prototyping.
>>
>> Having to dub initialize and pull in libraries is a pain for 
>> this. Python got it right with their package manager(s)
>
> I suggested this once but there seems to be a group of people 
> the viscerally oppose this.
> See: 
> http://forum.dlang.org/post/bdhmdbhyoirmwcbbxvln@forum.dlang.org

How would you select the package version you want to use. 
Obviously it would be fine for small scripts to pick the latest 
version, but no so much for non-trivial projects.

Somewhat related: I would love to be able to install packages 
with dub "globally", and then have them automatically added to 
the compiler's search paths and working with import with rdmd and 
dmd.

I install version 0.1 of package X globally and now all my 
programs pick that up with import. If the package is a library, 
dub would (re)compile then upon installation and put the 
resulting libs in the correct places so that all my programs can 
simply link to them.
I should also be able to override the global import with a 
different version at the project level if I which to do so. 
Similar to what dub.selections.json currently does.

Having dub fully integrated with the compiler and it's 
configuration would be a major quality of life improvement, and a 
nice step towards the "it just works" state. Much like C/C++ 
libraries get installed by Linux's package managers and just 
work, but for D.

Right now the easiest way to boot up a new project is to copy one 
that already exists, rename it, and edit the dub.json file to 
add/remove any dependencies. This gets old really quickly and is 
the only reason why D doesn't really feel like a scripting 
language for small projects, because setting up the environment 
and frequently used dependencies takes longer than writing the 
script, and you need a project directory instead of a single .d 
file that just uses all your common imports.