Dub (code.dlang.org) has emerged as the standard build tool for D. Yet
there doesn't look to be any mention of it on the D site proper...
Would it be reasonable to include dub with the DMD installer? Or failing
that, at least feature it prominently (or at all) on the tools page of
dlang.org?

Dub (code.dlang.org) has emerged as the standard build tool for
D. Yet
there doesn't look to be any mention of it on the D site
proper...
Would it be reasonable to include dub with the DMD installer?
Or failing
that, at least feature it prominently (or at all) on the tools
page of
dlang.org?

Yes. It is actually planned and I have heard full approval from
Andrei just yesterday. Main blocker is transition to SDL as
default project description format - we don't want to distribute
a tool with compiler and break something as fundamental as that
immediately after.
I was about to contact Sonke about possible moving of dub /
dub-registry to D-Programming-Language organization shortly after
DConf.

Yeah Sonke contributions to community are beyond any
imagination already. She should push for him and move forward
(assuming he is ok with it ;))

I agree. I have a project (and even handed in a paper about it*)
based on vibe.d. It was vibe.d that made me realize the project
in the first place. The whole thing is written in D (and bits in
C) and it was vibe.d that made me think "F***k me sideways, with
this we can make it available to everyone!", and I developed a
web-based app.
* Hope it will be accepted. Once it's official, I will publish it
here too. I want to give full credit to D and its community, of
course!

Can you elaborate? I find JSON to be precisely the right verbosity -
enough to be human readable, not too much.
Is the decision to switch documented/discussed somewhere? It seems
unnecessary to me, switching from a de-facto standard to something I've
never heard of...

Thanks.
Personally, I don't find the arguments for switching convincing. Perhaps
moving to an extended JSON that supports comments and other niceties, but
moving to an entirely new format seems excessive. The nice thing about
JSON is that it is commonly used everywhere, making dub easy to approach
and easy to write tooling for - even after a switch to SDL as the primary
format, I can see many folks and tooling continuing to use JSON. Without
removal of JSON support you are stuck supporting two formats...
tl;dr I think it is a bad idea.

Thanks.
Personally, I don't find the arguments for switching
convincing. Perhaps
moving to an extended JSON that supports comments and other
niceties, but
moving to an entirely new format seems excessive. The nice
thing about
JSON is that it is commonly used everywhere, making dub easy to
approach
and easy to write tooling for - even after a switch to SDL as
the primary
format, I can see many folks and tooling continuing to use
JSON. Without
removal of JSON support you are stuck supporting two formats...
tl;dr I think it is a bad idea.

I don't really see the point of it either. A reason for switching
doesn't jump out at me.

Thanks.
Personally, I don't find the arguments for switching convincing. Perhaps
moving to an extended JSON that supports comments and other niceties, but
moving to an entirely new format seems excessive. The nice thing about
JSON is that it is commonly used everywhere, making dub easy to approach
and easy to write tooling for - even after a switch to SDL as the primary
format, I can see many folks and tooling continuing to use JSON. Without
removal of JSON support you are stuck supporting two formats...
tl;dr I think it is a bad idea.

Nobody has said anything about removing JSON support. It's been stated
that JSON support is *staying* as an option. SDL will merely be the
recommended format.
Sayeth Sonke:
"The plan is to keep full support for the JSON based package description
and still use it for machine-to-machine communication, but at the same
time add the new format as the preferred way for developers to write."
-
https://github.com/rejectedsoftware/dub/wiki/Sdl-based-package-format-draft

Nobody has said anything about removing JSON support. It's been stated
that JSON support is *staying* as an option. SDL will merely be the
recommended format.

Yes - my point is that moving to SDL while keeping JSON just means you now
have two formats you need to support. This will likely have the effect of
fragmenting things, with any tooling needing to support both.

Nobody has said anything about removing JSON support. It's been stated
that JSON support is *staying* as an option. SDL will merely be the
recommended format.

Yes - my point is that moving to SDL while keeping JSON just means you now
have two formats you need to support. This will likely have the effect of
fragmenting things, with any tooling needing to support both.

Not really. "dub describe" takes care of that. And (if it doesn't
already) DUB really should also provide an API to directly query all a
package's info, letting DUB handle all the parsing.

Nobody has said anything about removing JSON support. It's been stated
that JSON support is *staying* as an option. SDL will merely be the
recommended format.

Yes - my point is that moving to SDL while keeping JSON just means you
now
have two formats you need to support. This will likely have the
effect of
fragmenting things, with any tooling needing to support both.

Not really. "dub describe" takes care of that. And (if it doesn't
already) DUB really should also provide an API to directly query all a
package's info, letting DUB handle all the parsing.

Exactly, the recommended way to work with package descriptions is always
to use "dub describe", or to use DUB as a library, which enables working
with packages on several abstraction levels.
There are a lot of package features that need to be supported and it
doesn't really make much sense to try and reimplement all of that in
every IDE - especially as long as the format isn't 100% stable.

Thanks.
Personally, I don't find the arguments for switching
convincing. Perhaps
moving to an extended JSON that supports comments and other
niceties, but
moving to an entirely new format seems excessive. The nice
thing about
JSON is that it is commonly used everywhere, making dub easy
to approach
and easy to write tooling for - even after a switch to SDL as
the primary
format, I can see many folks and tooling continuing to use
JSON. Without
removal of JSON support you are stuck supporting two formats...
tl;dr I think it is a bad idea.

Nobody has said anything about removing JSON support. It's been
stated that JSON support is *staying* as an option. SDL will
merely be the recommended format.
Sayeth Sonke:
"The plan is to keep full support for the JSON based package
description and still use it for machine-to-machine
communication, but at the same time add the new format as the
preferred way for developers to write."
-
https://github.com/rejectedsoftware/dub/wiki/Sdl-based-package-format-draft

That is not the issue.
The issue is with tools, e.g. an IDE or script wanting to support
Dub will have to have a dependency on an SDL parser (while pretty
much every language has a JSON parser in its standard lib and if
not a parser can be written in a few hours - on the other hand
SDL is very uncommon at the moment).
So you can't e.g. write a quick python util script without
requiring an external library.

My preference was also to go with lenient JSON (more or less as
described here:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/post/575 )
It is easier (than SDL) to understand if people already know JSON, and
there is some tool support in other languages already, should that be
necessary (I'm not sure it would be though). Also, it's easier to change
a proper JSON document into lenient JSON, it can just be done gradually.
To change to SDL, it has to be done all at once.
But admittedly, these are all very slim reasons. In the end there
wouldn't be that much of a difference if DUB went with SDL or
lenient-JSON. I think the main motivation for going with the later would
be that then we would have a D library for parsing lenient JSON, which
for the D community in general (that is, being just DUB usage) might be
more interesting than having an SDL one.
But in the end, because the differences are slim, I think lenient-JSON
would only be considered if there is D library support for it.
Bottomline is, SDL has a parser already.
I feel tempted to write the lenient JSON parser, it should not take take
long from an plain JSON one, but I'm kind swamped with lots of stuff I
want to do with DDT and other projects...
--
Bruno Medeiros
https://twitter.com/brunodomedeiros

Can you elaborate? I find JSON to be precisely the right verbosity -
enough to be human readable, not too much.
Is the decision to switch documented/discussed somewhere? It seems
unnecessary to me, switching from a de-facto standard to something I've
never heard of...

Do we want/need the SDL parser/writer to be included into
Phobos first?

This is my concern. Waiting for another module to get into phobos
before DUB gets included is too much. Couldn't SDL be added later
as an option? (For small files like this I find this to be a
bikeshed issue. DUB files are very readable as is and I don't
like the idea of waiting 6 more months (as is typical in D))

Do we want/need the SDL parser/writer to be included into
Phobos first?

This is my concern. Waiting for another module to get into
phobos before DUB gets included is too much. Couldn't SDL be
added later as an option? (For small files like this I find
this to be a bikeshed issue. DUB files are very readable as is
and I don't like the idea of waiting 6 more months (as is
typical in D))

I don't see it as a problem. dub and dub-registry will stay
separate repositories and won't be included in phobos or tools
repo so we can just let it go. I know that in general it is good
policy to keep official stuff phobos-only but here it is simply
unfeasible.
dub-registry itself depends on vibe.d anyway and it is not like
we are going to include _that_ into phobos :)

No, SDLang-D is absolutely fine, it's just me being overloaded with
other things.

Do we want/need the SDL parser/writer to be included into Phobos first?

I'd include it as a "git subtree" into the repository, so that this
wouldn't be necessary. This copy would only used when building DUB using
the build.sh/.cmd. When DUB itself is used as a package/library, it
would use the sdlang-d DUB package instead.

No, SDLang-D is absolutely fine, it's just me being overloaded with
other things.

Do we want/need the SDL parser/writer to be included into Phobos first?

I'd include it as a "git subtree" into the repository, so that this
wouldn't be necessary. This copy would only used when building DUB using
the build.sh/.cmd. When DUB itself is used as a package/library, it
would use the sdlang-d DUB package instead.

Ok, sounds good to me.
But maybe I should put a "std.sdlang" through the phobos review queue to
help getting DUB into the standard DMD releases?

But maybe I should put a "std.sdlang" through the phobos review queue to
help getting DUB into the standard DMD releases?

Not sure if that would be really considered necessary, but I wouldn't
mind that for sure in general* (I think it should be enough if the
repository doesn't have external dependencies). But please let's try to
establish something like std.data.sdl, so that the top level std package
doesn't get ever more crowded when new formats get added.
* It may also be a good step to solve the chicken-egg issue here, where
the argument is that because SDL isn't so common, it shouldn't be used.
I think it's a really nice little format that deserves to get some support.

* It may also be a good step to solve the chicken-egg issue here, where=20
the argument is that because SDL isn't so common, it shouldn't be used.=20
I think it's a really nice little format that deserves to get some suppor=

t.
It looks to me like what .INI files should have been defined
to be from day one. It looks like less like a data definition
language for computers than XML or even JSON with its raw
text file appearance of tags. Only the occasional {} or =3D
really remind you that there is a formal syntax to it.
--=20
Marco

Dub (code.dlang.org <http://code.dlang.org>) has emerged as the standard
build tool for D. Yet there doesn't look to be any mention of it on the
D site proper...
Would it be reasonable to include dub with the DMD installer? Or
failing that, at least feature it prominently (or at all) on the tools
page of dlang.org <http://dlang.org>?

I'd say it deserves mention, and so does Mono-D - it's an even more
complete IDE than VisualD, it even uses dub.json files for its workspace
configuration. I think it's important to have a download link for both
in the tools page, it gives D a modern feel.

Dub (code.dlang.org) has emerged as the standard build tool for
D. Yet
there doesn't look to be any mention of it on the D site
proper...
Would it be reasonable to include dub with the DMD installer?
Or failing
that, at least feature it prominently (or at all) on the tools
page of
dlang.org?

I've been wanting to add it for awhile now but was waiting for
Dub to be declared the official package manager (it is, of
course, the de facto package manager). Also Sönke would have a
say in whether or not he thinks it's a good idea.

Dub (code.dlang.org <http://code.dlang.org>) has emerged as the standard
build tool for D. Yet there doesn't look to be any mention of it on the
D site proper...
Would it be reasonable to include dub with the DMD installer? Or
failing that, at least feature it prominently (or at all) on the tools
page of dlang.org <http://dlang.org>?

Dub (code.dlang.org) has emerged as the standard build tool for
D. Yet
there doesn't look to be any mention of it on the D site
proper...
Would it be reasonable to include dub with the DMD installer?
Or failing
that, at least feature it prominently (or at all) on the tools
page of
dlang.org?

btw, Sonke has agreed to move dub and dub-registry repos to
D-Programming-Language organization where work on preparing first
distributed release will continue.
Currently awaiting for Walter to initiate actual transfer.