On Wednesday, 3 February 2016 at 11:22:50 UTC, Márcio Martins
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
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.
There are a few problems with it. For instance dub packages have
no information about the files in them, you can't ask dub for
derelict.opengl3.gl3.d, you ask it for the package derelict-gl3.
So for something like this to work, there would need to be some
type of syntax to import the package.
Probably something simple could be done like pragma(dub,
"derelict-gl3", "==1.0.12");. As far as I can tell a dub pragma
could be 100% ignored by the compiler unless a flag gets passed
to print the dub dependencies. Then a tool like rdmd that gets
all the imports for a file could also get all the dub
dependencies and call out to dub to download them and pass the
import paths for the dub dependencies to the final invocation of
dmd. Otherwise the dub pragma would really do nothing other than
be a signifier to outside tools. Tools like dcd could even use
the pragmas to automatically call out to dub to find the paths of
the dependencies and start indexing them for auto completion.
Really would be a great day to have that all automatically work.
Also dub could be packaged with dmd and make all this more simple.
Right now the easiest way to use dub is to make a .json for your
own project and build with dub, but honestly that sucks a lot
because really the only thing people want to use dub for is the
dependencies, the rest of it kinda gets in the way and is
annoying as hell to use. Like trying to figure out how to build
projects for x64 or unittests or whatever with dub is a pain. Its
not really what people want to use dub for, but it tries to pass
itself off as a build system which it sucks at.