RejectedSoftware Forums

Sign up

Pages: 1 2 3

Re: Alternative package description formats

On Thu, 14 Mar 2013 01:15:28 GMT
"Jonathan M Davis" jmdavisprog@gmx.com wrote:

I confess that I detest yaml due to the fact that it's whitespace
sensitive. json is far superior IMHO. As for SDL, the format seems a
bit off to me due to the complete lack of separators or delimiters on
most lines,

FWIW, SDL is a newline-terminated format with \ as a line-continuation
operator). Whitespace separates tokens. Names (when a tag isn't
anonymous) are identifiers (ie cannot have embedded whitespace) and are
the first token on a line. Any following tokens (if any) are values (and
then optionally Name=Value attributes, and then optionally a
block of children).

Don't know if that helps, but thought I'd point it out in case it
clarifies anything.

My vote, of course, goes for SDL. But as I'm the one who wrote the D
implementation, I could be considered biased ;)

I think that one key thing to remember is that if dub is trying to
become D's official package manager, it can't rely on external
libraries for anything (except for the standard library). So, any
package format that it supports either needs to be parseable with
Phobos or with dub's own code. json is the only one of the three
that's currently in Phobos (though std.json does need an overhaul).
So, if dub goes with SDL (or yaml), it either needs to an SDL parser
internally, or an SDL parser needs to be added to Phobos (though it's
quite possible that one could be used internally and then added to
Phobos later).

That's a good point. To that end:

  • DUB hereby has my full permission to steal/adapt/whatever any or all
    of my D SDL implementation. If it does so, then I'm willing to
    maintain DUB's internal copy of SDLang-D if Sonke would like.

  • It has always been my intent to offer SDLang-D to Phobos as a
    possible "std.sdlang". I just want to improve the API first, though.

Re: Alternative package description formats

On Thu, 14 Mar 2013 10:49:03 GMT
"Robert" jfanatiker@gmx.at wrote:

If non dub specific functionality would be accepted only if it was
part of dub's source code, I think this would just be cheating
without taking into account the original motivation for the
restriction that we should only depend on phobos.

AIUI, I think that restriction is just for the sake of practicality,
to keep it as easy as possible to bootstrap the official toolchain
and avoid any circular dependency awkwardness. So I don't think
baking-in functionality is cheating because that does (AIUI)
still take the original motivation into account.

Do you know any guidelines/restrictions on what libraries can become
part of phobos or not?

AFAIK, it's just:

  • The author allows it the be in Phobos.
  • It can be made Boost-licensed.
  • It passes the through the review process (which would include judging
    it to be general enough, useful enough and good enough to be in
    Phobos).

Re: Alternative package description formats

On Thu, 14 Mar 2013 17:59:01 -0400, Nick Sabalausky wrote:

AFAIK, it's just:

  • The author allows it the be in Phobos.
  • It can be made Boost-licensed.
  • It passes the through the review process (which would include judging

it to be general enough, useful enough and good enough to be in
Phobos).

Yeah. What can make it into Phobos is pretty broad as long as it's good and is deemed generally useful. The main reason that more stuff doesn't get in is that anyone who wants to get something in has to be fairly aggressive about it, pushing for it to be reviewed, and getting it through the review process, and a lot of programmers just aren't willing to go through that effort. The main hold-up for something like Tango is the license, but thus far, I believe it's always been the case that anything which has gone through the review process has been pushed through by the original author, which tends to eliminate license-related issues.

So, it would make perfect sense for a solid SDL implementation to make it into Phobos, but anything which is truly specific to dub really wouldn't belong, as it wouldn't be of general use.

Re: Alternative package description formats

Thank you guys!

Re: Alternative package description formats

On Thu, 14 Mar 2013 23:15:47 GMT, Jonathan M Davis wrote:

Yeah. What can make it into Phobos is pretty broad as long as it's good and is deemed generally useful. The main reason that more stuff doesn't get in is that anyone who wants to get something in has to be fairly aggressive about it, pushing for it to be reviewed, and getting it through the review process, and a lot of programmers just aren't willing to go through that effort. The main hold-up for something like Tango is the license, but thus far, I believe it's always been the case that anything which has gone through the review process has been pushed through by the original author, which tends to eliminate license-related issues.

So, it would make perfect sense for a solid SDL implementation to make it into Phobos, but anything which is truly specific to dub really wouldn't belong, as it wouldn't be of general use.

Both with SDL and Tango it would be possible to just include the library with the D distribution. If only the package manager would depend on it there would be no license issues.

Re: Alternative package description formats

On Sat, 09 Mar 2013 12:11:09 GMT, Sönke Ludwig wrote:

There has been some discussion about using a different format than JSON for the package description files. While this topic is techinically not particularily pressing, it would be good to know where to go with this early. The two candidates so far are YAML and SDL. JSON will still be supported for backwards compatibility and as the default format that is transferred over the network (package registry). The following sections list the pros/cons of each format and an example of how it could look like. My favorite so far is SDL, which was originally proposed by Nick Sabalausky, who also made a D implementation. So now I think it would be good to get some more input to get a collective opinion on this before implementing anything.

I find the JSON files somewhat tedious to write.
Having the unquoted tags helps to learn and remember the structure of the package files so I'm too in favor of SDL.
Also listing multiple dependencies instead of having to put them in a substructure is good.

Re: Alternative package description formats

As the SDL format seems to turn out as the generally favored choice (with the main concern of it not being a widely used format), I've started drafting a possible specification: https://github.com/rejectedsoftware/dub/wiki/Sdl-based-package-format-draft

It's currently a more or less literal translation of the JSON format, adapted to SDL specific features in some places (such as dependency or configuration lists).

Re: Alternative package description formats

What's the state of this?
Is someone working on SDL for dub?
I'm asking because I get regularly annoyed when writing the package.json
files (including weird parse error messages).

Re: Alternative package description formats

Am 09.11.2013 20:59, schrieb Martin Nowak:

What's the state of this?
Is someone working on SDL for dub?
I'm asking because I get regularly annoyed when writing the package.json
files (including weird parse error messages).

I personally didn't have time up to now. However, it should be possible
to allocate a day next week (the dub-registry project also needs be
changed to use dub as a library dependency to handle package files to
avoid redundancies). I'd also change the file names to "dub.json" and
"dub.sdl" respectively on that occasion (o/c keeping "package.json" for
backwards compatibility).

Re: Alternative package description formats

On 09/03/2013 12:11, Sönke Ludwig wrote:

There has been some discussion about using a different format than JSON for the package description files. While this topic is techinically not particularily pressing, it would be good to know where to go with this early. The two candidates so far are YAML and SDL. JSON will still be supported for backwards compatibility and as the default format that is transferred over the network (package registry). The following sections list the pros/cons of each format and an example of how it could look like. My favorite so far is SDL, which was originally proposed by Nick Sabalausky, who also made a D implementation. So now I think it would be good to get some more input to get a collective opinion on this before implementing anything.

Have you considered lenient JSON as an alternative?

Lenient JSON is a loosely defined extension to JSON that allows many of
the things that would make it a more succint and clear data format. For
a description of lenient JSON, see this:
http://developer.android.com/reference/android/util/JsonReader.html#setLenient%28boolean%29

It allows these extra syntaxes:

  • End of line comments starting with // or # and ending with a newline
    character.
  • C-style comments starting with / and ending with /. Such comments
    may not be nested.
  • Names that are unquoted or 'single quoted'.
  • Strings that are unquoted or 'single quoted'.
  • Array elements separated by ; instead of ,.
  • Unnecessary array separators. These are interpreted as if null was
    the omitted value.
  • Names and values separated by = or => instead of :.
  • Name/value pairs separated by ; instead of ,.

Some JSON parser/readers support this functionality already, so there is
also some tool support already (although not for D).

Pages: 1 2 3