On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky
wrote:
On 8/25/2014 6:14 PM, Idan Arye wrote:
On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler
wrote:
Hello everyone,
I've been working on SDL support for DUB and wanted to get
some
people's opinions on whether we should really use SDL. I've
posted my
thoughts here:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
You said that "The standard way to read a dub package
description is to
use the output of "dub describe", not to parse dub.json
directly", but
what about tools that *write* to dub.json?
...They *continue* writing to dub.json just as before?
I don't see the problem. "dub describe" isn't going to
magically start failing just because it was a machine that
wrote to dub.json instead of a human.
You did catch the part where people keep saying that support
for JSON is *not going anywhere*, right?
> Currently, if an IDE wants to
use DUB behind the scenes as it's build system it can parse
dub.json and
modify it as it wishes, and that should even work if someone
modified
dub.json by hand. But what if someone modifies dub.json by
hand and adds
ASON stuff to it?
Again, use "dub describe" to read the data, then write to
"dub.{whatever}".
> I think we need a command like `dub normalize` that'll
"dub describe"
convert the dub.json file into a pure JSON file
"dub describe"
>that has exactly the
same data, so IDEs could call it before loading dub.json.
I don't see the problem.
`dub describe` does not give you a normalized version of
"dub.json". It gives you something else:
$ dub init
Successfully created an empty project in '/tmp/dub-test'.
$ dub describe > dub.json.new
$ mv dub.json.new dub.json
$ dub describe
Error executing command describe: Got .name of type undefined -
expected string.
Sure, the data to build a new "dub.json" is in there - after all,
all the data DUB can provide is in there. But that's the problem
- *all* the data DUB can provide is in there. That includes data
from downloaded dependencies, system data, (possibly) local
configuration data and anything can be added in the future.
That's the point of `dub describe` - query for anything DUB can
tell you and let the user pick what they need.
Even if the result of `dub describe` were valid for "dub.json",
you wouldn't want to put all that data in the project's
build-file! You want to be able to put "dub.json" under source
control and for that it must only contain information about the
project - not about the specific configuration of the machine of
the last developer who happened to run `dub describe` and
overwrite "dub.json".
`dub describe` is perfect for automated tools that want to query
DUB, but it's not a solution for tools that need to modify it.
