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.
