Make dub part of the standard dmd distribution

[Nick Sabalausky via Digitalmars-d]

On 06/01/2015 02:49 PM, Steven Schveighoffer wrote:
> On 6/1/15 1:36 PM, Nick Sabalausky wrote:
>>
>> That sort of did what dub does, but badly. Among other things, it
>> directly encouraged developers to hardcode their exact dependencies. It
>> would have been a mess. Dub's package management side already handles
>> that DIP's goals WAY better. The *only* issue now is trying to opt-out
>> of dub's buildsystem side without causing problems (and I absolutely
>> believe that to be easily solvable, see my other posts).
>
> I'm not defending DIP11, just that the fact that it could be done
> without requiring an extra "dependencies" file. One thing I absolutely
> LOVE about git, is that when I do git status, if it sees a
> not-just-cloned repository, it gives me all the commands I would need to
> run to do all the various things. I rarely have to go to the git manual.
> I'd love to see something like the following:
>
>  > dmd x.d
> Error: Your import of some.lib.module didn't work. Running dub
> --with-some-cool-arg some.lib.module would fetch the correct module from
> code.dlang.org
>  > dub --with-some-cool-arg some.lib.module
> Dub : got it, fetched.
>  > dmd x.d
>  > echo 'yay, it worked! Too bad this is a fantasy :('
>

Yea, true, that would be nice.

However, once the dub PRs I'm working on now are finished, then you 
should be able to do something like this:

 > dmd x.d
Error: Your import of some.lib.module didn't work.
 > dub fetch libfoobar
 > dmd `dub describe libfoobar --dmd-args` x.d

And it should even be possible to add support for this stuff, even 
without a dub.json for the current project:

 > dmd x.d
Error: Your import of some.lib.module didn't work.
 > dub find-module some.lib.module
(searches the repo)
libfoobar
 > dmd `dub use libfoobar [optional-version] --dmd-args` x.d
(Auto-fetches libfoobar if it hasn't already been fetched, and then 
outputs the necessary CLI args for DMD to use.)


>>> The problem I have with dub is it makes you as a consumer of libraries
>>> live within its realm. You have to make a dub file to use it, and that's
>>> not a small burden.
>>>
>>
>> The dub.json file is an absolutely trivial "burden". It's a really,
>> REALLY simple little file. Or at least, it should be...
>
> Sorry, I suppose it's a small burden if you use dub frequently. I don't.
> Look what happens when I initialize a dub project:
>
> {
>      "name": "testdub",
>      "description": "A minimal D application.",
>      "copyright": "Copyright © 2015, steves",
>      "authors": ["steves"],
>      "dependencies": {
>      }
> }
>
> Cool, I can figure out how to massage all the existing strings, except,
> hm... dependencies. What goes in there?
>
> Now, it's time to get out the dub manual. annoying. Where is the comment
> that says "put your dependencies in here, they should look like this:
> ..."???
>
> And dub uses versions. How does that work? Again no comment.
>

There's really not much to remember. All you really need to remember is 
this:

"dependencies": {
     "libname": "==1.3.0"
}

That's really it.

There are fancier things you *can* do, but that right there is really 
all you need, nothing more.

Once dub supports a format that can actually freaking handle comments 
(*grumble grumble* stupid json *grumble grumble*), then dub init's 
generated file could be way more self-descriptive:

"dependencies": {
     // Uncomment these to use them:

     // Use an exact version:
     //     "name-of-lib": "==1.3.4",

     // Restrict to a certain minor version,
     // equivalent to ">=1.3.4 <1.4.0":
     //     "name-of-lib": "~>1.3.4",
}

> And where does the e.g. "name" get stuck into the executable? Oh, it
> doesn't. Why is it generated? I don't freaking know (except that it was
> the directory I was in when running dub init).
>

Name is just the name of the project. To identify it. Just like a Github 
project name. Or, pretty much anything called a "name", really. Every 
project has a name, dub or not. Not really hard to remember. There's no 
magic going on there.

And again, dub needs a format here that actually freaking supports comments.

> I'm sure dub is great for people who want to learn dub. For those who
> don't, it should work in a minimal way, and ESPECIALLY if we are to
> include it with the distribution.
>

It could be improved in some ways, but I think dub.json is way simpler 
then non-users really expect it to be. It just needs to communicate the 
minimal basics a little better, so people don't have to go trying to 
find <http://code.dlang.org/package-format> and then get intimidated by 
all the (mostly non-essential) stuff there. And of course, it needs the 
PRs I'm doing to make it way more friendly to non-dub buildsystems.