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.
