Before we implement SDL package format for DUB

[Idan Arye via Digitalmars-d]

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`