On Wednesday, 3 February 2016 at 11:22:50 UTC, Márcio Martins wrote:

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.

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.


Reply via email to