On 6/1/15 3:53 PM, Nick Sabalausky wrote:
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.)
I would like to see more automation like this, even if it means there
are some generated meta-files. But I'd like it to be dmd and dub working
together. For instance, dmd should check to see if dub can has already
fetched the dependency and use it (maybe with a switch enabled). Having
to do the whole "`dub use blah blah`" on the command line is hacky.
A protocol to be used between dmd and dub (or any other package fetcher)
would be a good first step.
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.
I think I mistakenly hastily chose "name" as the first thing that stuck
out as not being used, but it's actually probably the only one that *is*
used (to name the resulting binary), which actually makes sense. Pick
any of the other ones :)
And again, dub needs a format here that actually freaking supports
comments.
Yes, definitely. Does it have to be straight json?
-Steve
