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/bdhmdbhyoirmwcbbx...@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.

Reply via email to