Dub integrated into the compiler?

[Rikki Cattermole via Digitalmars-d]

On 27/10/2014 3:33 p.m., Tofu Ninja wrote:
> I don't think this is a new idea but it would be pretty awesome.
>
> So the idea is that the compiler could check dub for libraries that it
> can't find and automatically download and integrate them. It would
> essentially make all of dub seem like it was a part of the standard lib
> and make integrating dub into projects seamless.
>
> Something like "import derelict.opengl3.gl3;" could automatically
> trigger dub if the import was not found on any local path.
>
> It also might need some special syntax for version specifications.
>
> It would require some work on both sides. Obviously the compiler would
> need to change but dub would have to as well, I don't think currently
> there is any way to look up a dub package by an import statement alone.
>
>
>
> Pros:
> Greatly increase ease of dub use.
> Greatly increase libraries that "seem" to be a part of the std lib.
> Would solve the large vs small stdlib dilemma.
>
> Cons:
> Could degrade perceived quality of stdlib if bad dub packages got in.
> Would mean some things could not be compiled without an internet
> connection.
>
> My answers to those cons would be
>
> 1)
> It might require some policing to make sure quality stays high.
> Maybe even with votes on what dub packages could automatically be picked
> up by this similar to how packages get into phobos but with a much lower
> bar.
>
> Also maybe a different import syntax for these imports to clearly
> differentiate them so that we can draw a line between the standard lib
> and dub. (personally I don't like that idea, I like the idea of seamless
> integration)
>
> 2)
> Normal code would still compile like normal, this would only open up the
> option of automatic library download for basically the 99% of people who
> always have an internet connection.
>
>
>
>
> So yeah...
> Thoughts?

Just an idea, but we could take a leaf out of lua's book in this case.
Lua has the require statement. Which includes external scripts and is 
highly configurable in lua code.

With skeleton[0] I have my repository/file downloaded hooked into 
require. It uses a very specific format. E.g. skeleton at rikkimax means a 
repository for username rikkimax, but it can go one step further 
skeleton at rikkimax/file.d for a singular file.
There's more to it then just that but small recap.

For singular files import could be used quite well for this format.
import repo at user/foo.bar;

For that module the file loader handler within dmd could be switched out 
to that repository.

But that's not really dub support. So next step:
import repo at user/p1/foo.bar;

Repository for user, in directory p1 with foo.bar module.
Location of dub library is in p1.

That's a little better.
But it doesn't explain how to get support between dmd and dub.

First the reading of files (either passed in via cli or via import's) 
would have to be abstracted out in dmd. Basically who handles the import 
statement.
Next dub would need a new compiler support which would act as a callback 
instead of directly running dmd. Except when compiling dependencies. It 
would also need to use the existing settings of the host dmd call (to 
emulate as if dub was doing dependency compilation).

Okay now this is getting a little scary for feature set of dmd not to 
mention dmd requiring D program gah yeah no.
So, shared library plugins for dmd to enable this as an optional 
feature? Sounds like a good idea.

Of course we can go one step further and add in support for e.g. gists, 
pastebin, dpaste and of course plain text files stored on a web server.

Lastly, versions.

@version(`>=0.2.1`)
import repo at user;

[0] https://github.com/rikkimax/skeleton