Before we implement SDL package format for DUB

[Nick Sabalausky via Digitalmars-d]

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.