On Thursday, 26 November 2015 at 09:21:33 UTC, Kagamin wrote:
> On Wednesday, 25 November 2015 at 20:24:36 UTC, Andrei Alexandrescu wrote:
>> I need to trust our core contributors here to make the right high-level decisions and execute them accurately when I'm not looking.
>
> I believe people do try to account for your possible opinion when making decisions, but your opinion is too inconsistent to be predictable, instead you always make judgement calls. You can't trust people because they don't know what is the right decision in your opinion.

This.

Sorry, Andrei, but you are absolutely terrible at management, at least at managing open-source project. Especially when compared to how brilliant you are as engineer and computer scientist.

I wouldn't normally bring attention to this topic to avoid starting yet another flame exchange but insulting Sonke in this thread was really pushing the limit. Especially considering it is _your_ personal failure as a leader to not react to one of announcements and discussions in time. With such attitude you will only alienate few hard working contributors which make D happen.

On 26/11/2015 6:45 PM, Jacob Carlborg wrote:
> On 2015-11-25 20:02, Walter Bright wrote:
>
>> Note 2: I intend to migrate the dmd.conf file format to json.
>
> What's the gain here compared to the breakage it will cause?
>

We get to delete the non-boost INI parser from the frontend!

On Thursday, 26 November 2015 at 10:28:15 UTC, Dragos Carp wrote:
> On Thursday, 26 November 2015 at 10:19:13 UTC, Mike Parker wrote:
>>
>> This is not even an issue. IDEs can create a dub.json for all new projects and call 'dub describe' on imported projects without ever touching SDLang. Again, *there is no problem here*.
>
> 'dub describe' has one big issue. It works only if you manage your packages in $HOME/.dub. Integrating 'dub describe' in another build tool with a different directory layout is currently impossible.
>
> Parsing the dub.json files directly from the external build tool ('rake' in my case) was doable and reasonably easy, with dub.sdl not anymore.

Pretty sure it works fine with anything that dub knows about.

dub add-path or dub add-local should put things on an even footing with ~/.dub in that regard.

V Thu, 26 Nov 2015 05:45:56 +0000
Mike Parker via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:

> On Thursday, 26 November 2015 at 04:42:14 UTC, David DeWitt wrote:
> 
> >
> > Is there any document explaining how to default to JSON so it isn't necessary to specify each time? Also SDL isn't the default so if they both stay shouldn't the discussion be which is the default or if the user chooses their preference at sometime after install (maybe first project)?
> 
> If it's really so painful to type 'dub init -fjson', then sure, let's revert to JSON as the default and the rest of us can type -fsdl. I never use 'dub init' anyway, so I have no personal stake in which is the default.

Thats not a problem. What I dont like is to have two formats for one thing. I don't care which one will be used (OK I maybe prefere JSON because of tooling and SDL because of syntax :)), but there should be only one format. Having more formats complicates everything.

1) You have to describe both variants

2) People using dub probably need to know both formats

3) When writing some tool or IDE you need to support both variants (no
dub describe does not solve this)

Btw. when your book will be published? :)

On Thursday, 26 November 2015 at 11:49:25 UTC, John Colvin wrote:
>
> Pretty sure it works fine with anything that dub knows about.
>
> dub add-path or dub add-local should put things on an even footing with ~/.dub in that regard.

`dub add-path` and `dub add-local` permanently add the specified paths to `~/.dub/packages/local-packages.json`. So this means that `~/.dub` is still special. and additional steps are necessary to keep this file clean.

Better it would be to able to specify this path on calling `dub describe`.

On 2015-11-26 09:33, Vladimir Panteleev wrote:

> INI files are the closest thing to that. You probably have a lot of
> INI-like files in your /etc/.
>
> Rust's Cargo uses TOML, which is a structured extension of INI.

I think Go uses TOML. I have at least seen several Go projects who're using. GitLab CI multi runner, for example.

[1] https://gitlab.com/gitlab-org/gitlab-ci-multi-runner

-- 
/Jacob Carlborg

On 2015-11-25 17:22, Joakim wrote:

> Converters like these would banish all these bikeshed arguments about
> code formatting or config formats, but what would we argue about then?
> We'd have to start debating religion or politics. :)

I'm sure there are a lot of other bikesheds that need (re)painting :)

-- 
/Jacob Carlborg

On 2015-11-25 11:17, Suliman wrote:
> I think that using SDL format was big mistake. Not only I do not want to
> spend time in learning yet another dead config format that now use only
> one project -- DUB. In time when DUB used json it was not perfect, but
> at last it was standard and everybody can read it.
>
> Now when I come to code.dlang.org I can't simply do copy-past of
> dependence. I need go to docs page, and read how to include it.
>
> Also I do not see any projects that are migrate to SDL. Everybody
> continue to use JSON. So please, return JSON back as default, or very
> soon we will see that nobody do not submit packages to code.dlang.org
> and nobody do not use DUB for their own projects.
>
> Please vote about SDL config format
> http://www.easypolls.net/poll.html?p=565587f4e4b0b3955a59fb67
>
> If SDL will stay by default I will prefer to move to any other build
> system or will downgrade to old version of DUB.

BTW, why was not TOML [1] chosen? I know it was discussed but I can't remember why SDL was preferred. I think TOML is more widely used than SDL [2]. GitLib CI multi runner is also using it.

[1] https://github.com/toml-lang/toml
[2] https://github.com/toml-lang/toml#projects-using-toml

-- 
/Jacob Carlborg

On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg wrote:
> On 2015-11-25 11:17, Suliman wrote:
>> [...]
>
> BTW, why was not TOML [1] chosen? I know it was discussed but I can't remember why SDL was preferred. I think TOML is more widely used than SDL [2]. GitLib CI multi runner is also using it.
>
> [1] https://github.com/toml-lang/toml
> [2] https://github.com/toml-lang/toml#projects-using-toml

TOML looks nice, _but_ it's version 0.4.0. We cannot afford to maintain a parser for a format that hasn't "settled down" yet.

V Thu, 26 Nov 2015 12:43:52 +0000
Chris via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:

> On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg wrote:
> > On 2015-11-25 11:17, Suliman wrote:
> >> [...]
> >
> > BTW, why was not TOML [1] chosen? I know it was discussed but I can't remember why SDL was preferred. I think TOML is more widely used than SDL [2]. GitLib CI multi runner is also using it.
> >
> > [1] https://github.com/toml-lang/toml
> > [2] https://github.com/toml-lang/toml#projects-using-toml
> 
> TOML looks nice, _but_ it's version 0.4.0. We cannot afford to maintain a parser for a format that hasn't "settled down" yet.

Ok, but we can afford to mantain a parser for a dead format? https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Simple_Declarative_Language