On Wednesday, 27 August 2014 at 19:06:29 UTC, Nick Sabalausky
wrote:
On 8/27/2014 2:38 PM, Idan Arye wrote:
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.
Ok, I see now. Yea, that could be improved. Luckily it
shouldn't be a difficult feature to add, though.
`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.
Well, it would probably work, it just wouldn't be an ideal
solution. But again, that "dub normalize" you suggest (or "dub
describe --normalize" or something) should do the trick. So it
doesn't appear to be a deal-breaker for supporting another
language, it's just an additional TODO for dub.
I don't like `dub describe --normalize` - it implies that the
regular `dub describe` is in some non-normalize format and adding
this flag will normalize the output. If you want to add
normalization as a `dub describe` flag, I'd prefer something like
`dub describe --buildfile-only`
