On Monday, 1 February 2016 at 11:42:54 UTC, Daniel Murphy wrote:
> The process will be complete when you've backported the entirety of 2.068.

From what I recall, 2.068 was fairly painless to merge anyway compared to other releases.

 — David

PvDda> I hope D GUI will be usable some day for me and other people not PvDda> wanting to fight with tools (and external libraries).

Oh  yeah!  I  find  this  library  the  most  adequate  (and  the most
accessible, btw). But unfortunately it seems abandoned :(.


Andre

On 1/29/16 11:07 AM, Adam D. Ruppe wrote:
> 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.

I suggested that at a point, it was destroyed. -- Andrei

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)

On Fri, 29 Jan 2016 16:07:48 +0000, Adam D. Ruppe wrote:

> 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.

That's how Go does it. It's not the case that Go doing things one way means that you should do the opposite, but it is an indication that you should look for other examples before following suit.

In the case of dependencies, they should always be versioned. The language and standard library should be stable enough that you don't have to specify a version you  depend on -- though that isn't always true. So are you going to include a version specifier in import statements now? That would be awkward.

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/bdhmdbhyoirmwcbbxvln@forum.dlang.org

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

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.

On Wednesday, 3 February 2016 at 23:35:21 UTC, Tofu Ninja wrote:
> ...

Actually now that I think about it, you can do with out the pragma and just define something like this...

mixin template DubDependency(string dependency, string vers)
{
	// Does nothing but print a dependency
	version(Dub_Dependency){
		pragma(msg, "DubDependency: \"" ~ dependency ~ "\" \"" ~ vers ~ "\"");
	}
}


Then whenever you need it you just put:
mixin DubDependency!("derelict-gl3", "==1.0.12");

And to get the dependencies for a file you can just do
dmd test.d -o- -version=Dub_Dependency

On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:
> In theory it's completely irrelevant as to whether is something is in the standard library or can just be imported via dub or a git clone, but in practice that's not the case.

In support of this statement in particular I'd like to point out that there are many environments which, for various reasons of security and policy, often require that any 3rd-party libraries not included as a language's standard be explicitly vetted by teams of very slow-moving people who seem to actively enjoy paperwork. In practice this means that non-standard libraries simply don't get used in those environments. That said, if a library gets popular enough (Boost, parts of Apache), they might manage to get pre-vetted and still used in these situations.

I'm not really offering a good solution to the debate, I just wanted to make a note of this.