On 2013-09-13 10:22, Sönke Ludwig wrote:

> I have to admit that looking at the examples *now* leaves me with a
> strong distaste for YAML. That wasn't the case in the beginning, but
> now, after not having looked at any YAML document since then and even
> with only the simplest syntax constructs used, it just looks confusing
> to me.
>
> Some points that stand out:
>
>   - Built-in field names and user defined dictionary key (can) look the
>     same and can be quite confusing (my initial reaction to the
>     "sub-package:" line in the example was "Hmm.. what kind of command
>     is *that*?")
>
>   - Indentation based scoping is much less explicit than braces. Someone
>     who has never seen the format may well think that it's just visual
>     formatting and has to read up on it first.
>
>   - It still has the deep nesting of the JSON format
>
>   - The complexity of the specification is a bit of a turn-off, too
>
> Having said that, YAML for sure is a nice format for many things and
> considerably more powerful in some areas than f.ex. SDL, but here I
> think the focus should be on the most concise and intuitive textual
> representation and IMO SDL does a better job there. More advanced
> features of YAML, if needed, can also easily be simulated with SDL.

Here's a lightly modified version of the YAML example:

name: my-package
description: A package for demonstration purposes
dependencies:
  vibe-d: ">=0.7.13"
  sub-package: { version: ~master}

configurations:
  # command line version
  - name: console
    targetType: executable
    versions: ConsoleApp

  # Win32 based GUI version
  - name: gui
    targetType: executable
    versions: UseWinMain
    libs-windows: [gdi32, user32]

I have used the inline format for "sub-package" and "libs-windows". I'm also assuming it's possible to use a single value instead of an array for "versions".

Don't know about SDL, but YAML allow you to have references, like this:

configurations:
  # command line version
  - name: console &console
    targetType: executable
    versions: ConsoleApp
    libs-windows: [gdi32, user32]

  # Win32 based GUI version
  - name: gui
    <<: *console
    versions: UseWinMain

-- 
/Jacob Carlborg

On 9/13/13, Sönke Ludwig <sludwig@outerproduct.org> wrote:
>> Here's the discussion about JSON vs. YAML vs. SDL on the dub forum:
>>
>> http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/

Can we specify values on multiple lines? E.g. this line:

libs-windows "gdi32" "user32"

To somehow use multi-line instead:

libs-windows
    "gdi32"
    "user32"

Even if we have to use the slash key for continuation (like in some languages) it would be useful to have, since it's then easy to quickly comment out a value by commenting out the entire line (well I have a key shortcut to quickly comment/uncomment a line, I'd like to be able to use it.).

Am 13.09.2013 17:03, schrieb Andrej Mitrovic:
> On 9/13/13, Sönke Ludwig <sludwig@outerproduct.org> wrote:
>>> Here's the discussion about JSON vs. YAML vs. SDL on the dub forum:
>>>
>>> http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/
>
> Can we specify values on multiple lines? E.g. this line:
>
> libs-windows "gdi32" "user32"
>
> To somehow use multi-line instead:
>
> libs-windows
>      "gdi32"
>      "user32"
>
> Even if we have to use the slash key for continuation (like in some
> languages) it would be useful to have, since it's then easy to quickly
> comment out a value by commenting out the entire line (well I have a
> key shortcut to quickly comment/uncomment a line, I'd like to be able
> to use it.).
>

Both of these should work:

libs-windows \
  "gdi32" \
  "user32"

libs-windows "gdi32"
libs-windows "user32"

Am 13.09.2013 14:48, schrieb Jacob Carlborg:
> Here's a lightly modified version of the YAML example:
>
> name: my-package
> description: A package for demonstration purposes
> dependencies:
>    vibe-d: ">=0.7.13"
>    sub-package: { version: ~master}
>
> configurations:
>    # command line version
>    - name: console
>      targetType: executable
>      versions: ConsoleApp
>
>    # Win32 based GUI version
>    - name: gui
>      targetType: executable
>      versions: UseWinMain
>      libs-windows: [gdi32, user32]
>
> I have used the inline format for "sub-package" and "libs-windows". I'm
> also assuming it's possible to use a single value instead of an array
> for "versions".

That does indeed improve it. But I still think that the multitude of formatting options can be confusing and it takes more artistic skills to get a nice result than with a single clean way to format.

>
> Don't know about SDL, but YAML allow you to have references, like this:
>
> configurations:
>    # command line version
>    - name: console &console
>      targetType: executable
>      versions: ConsoleApp
>      libs-windows: [gdi32, user32]
>
>    # Win32 based GUI version
>    - name: gui
>      <<: *console
>      versions: UseWinMain
>

That's where IMO it gets hairy. It's for sure a highly useful feature, but also completely impossible to understand without consulting the documentation. SDL doesn't have direct support, but it would be possible build some kind of custom functionality if it proves useful.

Something like:

def somevar="somevalue"
libs "$somevar"

or

template "sometemplate" {
  libs "gdi32" "user32"
}

configuration "gui" {
  mixin "sometemplate"
}

On 9/13/13, Sönke Ludwig <sludwig@outerproduct.org> wrote:
> Both of these should work:
>
> libs-windows \
>    "gdi32" \
>    "user32"
>
> libs-windows "gdi32"
> libs-windows "user32"

Great!

On 11/09/2013 12:30, Sönke Ludwig wrote:
> Am 11.09.2013 11:57, schrieb Jacob Carlborg:
>> On 2013-09-10 22:48, Andrei Alexandrescu wrote:
>>> We've been experimenting with http://code.dlang.org for a while and
>>> things are going well. In particular Sönke has been very active about
>>> maintaining and improving it, which brings further confidence in the
>>> future of the project.
>>>
>>> We're considering making dub the official package manager for D. What do
>>> you all think?
>>
>> Unfortunately I have to say no to its current state.
>>
>> The biggest issue I have with dub is that it's really doesn't install
>> packages, at least not in the traditional sense. I cannot just run "dub
>> install foo" and then "foo --help". It will only clone the repository,
>> not install, or install anything. It basically only supports source
>> packages, which makes it mostly useless for tools/application compiling
>> to executables.
>>
>> I would say, compiling and installing executables is a must. It would be
>> nice if it could compiling libraries as well.
>
> Right now it is a pure development tool. It would be very nice to have
> end user installs somehow supported (either by directly installing
> application packages or by generating OS specific packages such as DEB
> or RPM). But since this enters a highly operating specific area and goes
> into direct competition with the OS package manager, I think it needs a
> lot of thought and caution to be generally useful and not possibly do
> more harm than good in the end. But yes, it should be a primary goal in
> my opinion, too.

Whoa, no. Application/executable install management as a goal would be a ridiculously bad idea.
Because that would sit at the wrong abstraction level. The OS package manager should not be tied to a particular language to compile packages from. Does it makes any sense to have to use D's package manager if my cmd-line util is written in D, but if I have a C++ or Go derived executable, I would have to use a different package manager for each? And what if I want my tool to depend (at runtime) on an executable generated from another language? Devise a mechanism for cross-package-manager interoperaction?...
Ridiculous. An application/executable manager should be language agnostic (and not even require compilation).

What dub should be first and foremost is a structured build tool (and build specification) for D projects.

-- 
Bruno Medeiros - Software Engineer

On 10/09/2013 21:48, Andrei Alexandrescu wrote:
> We've been experimenting with http://code.dlang.org for a while and
> things are going well. In particular Sönke has been very active about
> maintaining and improving it, which brings further confidence in the
> future of the project.
>
> We're considering making dub the official package manager for D. What do
> you all think?
>
>
> Andrei

I support making dub the official *structured build tool* for D.

There seems to be a long-standing confusion and dissonance on what a package manager should do, and what would be best for D.

I think what would be of the most benefit to D would be to have a structured build tool (and standard build specification). That is, there would a standard way to specify how to build D projects, supporting multiple configurations, and versioned dependencies (all done in a way such that the build tool is able to automatically fetch and manage the dependencies). These goals are well matched by dub.

But this is all for development-time usage. To have the same tool try to be an executable installation manager is another thing entirely and, in my opinion quite ill-suited for dub (see related OP). Where did this idea even come from??


-- 
Bruno Medeiros - Software Engineer

On Wednesday, 25 September 2013 at 15:51:47 UTC, Bruno Medeiros wrote:
> Whoa, no. Application/executable install management as a goal would be a ridiculously bad idea.
> Because that would sit at the wrong abstraction level. The OS package manager should not be tied to a particular language to compile packages from. Does it makes any sense to have to use D's package manager if my cmd-line util is written in D, but if I have a C++ or Go derived executable, I would have to use a different package manager for each? And what if I want my tool to depend (at runtime) on an executable generated from another language? Devise a mechanism for cross-package-manager interoperaction?...
> Ridiculous. An application/executable manager should be language agnostic (and not even require compilation).
>
> What dub should be first and foremost is a structured build tool (and build specification) for D projects.

There is a quite extensive discussion on topic here: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/274/ (~ second half), you may want to help me push that idea :P

On 2013-09-25 17:51, Bruno Medeiros wrote:

> Whoa, no. Application/executable install management as a goal would be a
> ridiculously bad idea.
> Because that would sit at the wrong abstraction level. The OS package
> manager should not be tied to a particular language to compile packages
> from. Does it makes any sense to have to use D's package manager if my
> cmd-line util is written in D, but if I have a C++ or Go derived
> executable, I would have to use a different package manager for each?
> And what if I want my tool to depend (at runtime) on an executable
> generated from another language? Devise a mechanism for
> cross-package-manager interoperaction?...
> Ridiculous. An application/executable manager should be language
> agnostic (and not even require compilation).

Instead I need to package my application and libraries for all the various of package managers out there. Not to mention neither Mac OS X or Windows comes with a package manager installed by default.

It's like buying a car. I buy a car for getting from A to B. I have bought my car and prepares to get from A to B. The car won't start, hmm ..., oh it has no engine. I have to figure out myself how to buy and install the engine. It's only half way there.

It's the same with dub. I install a package to use the tool. But wait, it actually _don't_, it just clones the repository.  I have to figure out myself how to compile and install the tool. It's only half way there.

> What dub should be first and foremost is a structured build tool (and
> build specification) for D projects.

There's nothing wrong with being a build tool. But currently dub tries to be way more than a build tool. I don't think a build tool should have any business in downloading packages, or download anything.

-- 
/Jacob Carlborg

On 2013-09-25 18:14, Bruno Medeiros wrote:

> But this is all for development-time usage. To have the same tool try to
> be an executable installation manager is another thing entirely and, in
> my opinion quite ill-suited for dub (see related OP). Where did this
> idea even come from??

If dub doesn't install packages, why the h*ll should I use it in the first place? I can just use the system package manager.

-- 
/Jacob Carlborg