Before we implement SDL package format for DUB

[Idan Arye via Digitalmars-d]

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.