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@rikkimax means a
repository for username rikkimax, but it can go one step further
skeleton@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@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@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@user;
[0] https://github.com/rikkimax/skeleton
