dub: should we make it the de jure package manager for D?

[Andrei Alexandrescu]

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

[Brad Anderson]

On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei

Post by Andrei Alexandrescu
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 vote yes but only if S?nke feels it is ready. I suspect he has
a few things he'll probably want done before this happens (the
potential switch from JSON to SDL comes to mind).

[Nick Sabalausky]

On Tue, 10 Sep 2013 23:01:12 +0200

Post by Brad Anderson
I vote yes but only if S?nke feels it is ready. I suspect he has
a few things he'll probably want done before this happens (the
potential switch from JSON to SDL comes to mind).

I assume that would be a backwards-compatible change. Make SDL the
preferred, but keep JSON in service.

[Sönke Ludwig]

Post by Nick Sabalausky
On Tue, 10 Sep 2013 23:01:12 +0200

Post by Brad Anderson
I vote yes but only if S?nke feels it is ready. I suspect he has
a few things he'll probably want done before this happens (the
potential switch from JSON to SDL comes to mind).

I assume that would be a backwards-compatible change. Make SDL the
preferred, but keep JSON in service.

Exactly. Given enough interest, we could also make a more formal review
process for a future SDL based format to ensure a maximum chance of a
solid, forward compatible format.

Of my former list mentioned in the VisualD thread [1], only package
signing is really still missing, but that's probably not mission
critical for now. The command line build process also needs to be
improved one way or another at some point (mostly caching pre-compiled
dependencies), but that also isn't really a strong argument anymore.

All in all I'd say that the things that are in the package format [2] by
now form a pretty solid basis to move forward without worrying too much
about future breakage.

[1]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/post/79
[2]: http://code.dlang.org/package-format

[Brad Anderson]

On Wednesday, 11 September 2013 at 06:12:41 UTC, S?nke Ludwig

Post by Sönke Ludwig

Post by Nick Sabalausky
On Tue, 10 Sep 2013 23:01:12 +0200

Post by Brad Anderson
I vote yes but only if S?nke feels it is ready. I suspect he
has
a few things he'll probably want done before this happens (the
potential switch from JSON to SDL comes to mind).

I assume that would be a backwards-compatible change. Make SDL the
preferred, but keep JSON in service.

Exactly. Given enough interest, we could also make a more
formal review process for a future SDL based format to ensure a
maximum chance of a solid, forward compatible format.
Of my former list mentioned in the VisualD thread [1], only
package signing is really still missing, but that's probably
not mission critical for now. The command line build process
also needs to be improved one way or another at some point
(mostly caching pre-compiled dependencies), but that also isn't
really a strong argument anymore.
All in all I'd say that the things that are in the package
format [2] by now form a pretty solid basis to move forward
without worrying too much about future breakage.
http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/post/79
[2]: http://code.dlang.org/package-format

Perhaps there should be a version number in the package format so
it can be changed when needed without a lot of headache and
breakage.

[Lionello Lunesu]

I vote yes but only if S?nke feels it is ready. I suspect he has a few
things he'll probably want done before this happens (the potential
switch from JSON to SDL comes to mind).

SD-what?! Why would alienate people even more than we already do?

L.

[Nick Sabalausky]

On Wed, 11 Sep 2013 21:10:46 +0800

Post by Lionello Lunesu

I vote yes but only if S?nke feels it is ready. I suspect he has a
few things he'll probably want done before this happens (the
potential switch from JSON to SDL comes to mind).

SD-what?! Why would alienate people even more than we already do?
L.

----------------------------
{
"name": "myproject",
"description": "A little web service of mine.",
"authors": ["Peter Parker", "Joe Contrib"],

"dependencies": {
"vibe-d": ">=0.7.11",
"mylib:component1": "~master",
"mylib:component2": "~master"
},

"subPackages": [
{
"name": "component1",
"targetType": "library",
"sourcePaths": ["source/component1"]
},
{
"name": "component2",
"targetType": "library",
"sourcePaths": ["source/component2"]
}
]
}
----------------------------

vs:

----------------------------
name "myproject",
description "A little web service of mine."
authors "Peter Parker" "Joe Contrib"

dependencies {
vibe-d ">=0.7.11"
mylib:component1 "~master"
mylib:component2 "~master"
}

subPackage {
name "component1"
targetType "library"
sourcePaths "source/component1"
}

subPackage {
name "component2"
targetType "library"
sourcePaths "source/component2"
}
----------------------------

That's why.

Besides, the JSON form wouldn't be going away anyway, it'd still be
kept.

[John Colvin]

On Wednesday, 11 September 2013 at 13:39:02 UTC, Nick Sabalausky

Post by Nick Sabalausky
On Wed, 11 Sep 2013 21:10:46 +0800

Post by Lionello Lunesu

I vote yes but only if S?nke feels it is ready. I suspect he has a
few things he'll probably want done before this happens (the
potential switch from JSON to SDL comes to mind).

SD-what?! Why would alienate people even more than we already
do?
L.

----------------------------
{
"name": "myproject",
"description": "A little web service of mine.",
"authors": ["Peter Parker", "Joe Contrib"],
"dependencies": {
"vibe-d": ">=0.7.11",
"mylib:component1": "~master",
"mylib:component2": "~master"
},
"subPackages": [
{
"name": "component1",
"targetType": "library",
"sourcePaths": ["source/component1"]
},
{
"name": "component2",
"targetType": "library",
"sourcePaths": ["source/component2"]
}
]
}
----------------------------
----------------------------
name "myproject",
description "A little web service of mine."
authors "Peter Parker" "Joe Contrib"
dependencies {
vibe-d ">=0.7.11"
mylib:component1 "~master"
mylib:component2 "~master"
}
subPackage {
name "component1"
targetType "library"
sourcePaths "source/component1"
}
subPackage {
name "component2"
targetType "library"
sourcePaths "source/component2"
}
----------------------------
That's why.
Besides, the JSON form wouldn't be going away anyway, it'd
still be
kept.

Why not YAML? It's cleaner than JSON and is very widely known.

[Brad Anderson]

On Wednesday, 11 September 2013 at 14:11:11 UTC, John Colvin

Post by John Colvin
Why not YAML? It's cleaner than JSON and is very widely known.

YAML is nice but can be surprisingly tricky to write by hand
sometimes (especially for people not used to significant
whitespace).

Here's the discussion about JSON vs. YAML vs. SDL on the dub
forum:

http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/

[Sönke Ludwig]

Post by John Colvin
Why not YAML? It's cleaner than JSON and is very widely known.

YAML is nice but can be surprisingly tricky to write by hand sometimes
(especially for people not used to significant whitespace).
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/

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.

[Jacob Carlborg]

Post by Sönke Ludwig
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.
- 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

[Sönke Ludwig]

Post by Jacob Carlborg
name: my-package
description: A package for demonstration purposes
vibe-d: ">=0.7.13"
sub-package: { version: ~master}
# 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.

Post by Jacob Carlborg
# 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"
}

[Andrej Mitrovic]

Post by Brad Anderson
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.).

[Sönke Ludwig]

Post by Andrej Mitrovic

Post by Brad Anderson
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/

libs-windows "gdi32" "user32"
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"

[Andrej Mitrovic]

Post by Sönke Ludwig
libs-windows \
"gdi32" \
"user32"
libs-windows "gdi32"
libs-windows "user32"

Great!

[Jonathan M Davis]

Post by John Colvin
Why not YAML? It's cleaner than JSON and is very widely known.

YAML is just plain evil. It doesn't ignore whitespace.

- Jonathan M Davis

[H. S. Teoh]

Post by Jonathan M Davis

Post by John Colvin
Why not YAML? It's cleaner than JSON and is very widely known.

YAML is just plain evil. It doesn't ignore whitespace.

[...]

It's funny. I used to think Python is evil for the same reason, but
after having played with it a little (mostly in SCons build scripts,
though, not full-fledged Python programs), I've come to actually like
it. It *is* rather refreshing to _not_ have those cascading '}'s
trailing every function body, taking up precious screen real estate. And
reindenting code doesn't require tedious checking to make sure those {'s
and }'s still line up as they ought.

I'd say that it's an acquired taste, at least for me. :)

But I've never used YAML, so I can't say whether or not I'd like it.

One thing I find lacking in these purported configuration file formats,
is the lack of built-in facility for cascading, and formatting long
values nicely. In my own personal projects, I use a format that allows
cascading, in which the program first loads a base configuration, which
is then selectively overridden by subsequent configuration files
specified by the user, command-line arguments, or direct user input, of
which there can be arbitrarily many overlays. This is especially useful
in programs where you run many times, each time with mostly the same
settings as the previous time, just slightly tweaked. Instead of
retyping (or copy-n-pasting, or scroll history + edit) 50 different
settings each time, you put them into files containing 5-10 settings
each (in fact, one file for each variant of the same 5-10 settings, if
you're so inclined), and freely combine them in various ways, plus
specify a few on-the-fly settings on the command-line, say.

As for long values, I've always disliked the fact that almost all
formats provide a way to wrap them across multiple lines, but almost
none of them let you indent the result nicely without also changing the
value. This is important for complex configuration formats that have
nested groups of settings. In my format, the syntax is specifically
catered for this use case, for example:

# This is a comment
value1 = "This is a very long value \
\split across multiple \
\lines."
value2 = "A short value"

module1 {
# These values are in a nested scope, so they are
# distinct from the settings above.
value1 = "This is another long \
\value split across \
\multiple lines."
value2 = "This is a value \
\with an embedded \ # a long value
\comment!"
}

The \'s at the end of the line begin a continuation escape sequence that
spans until the first \ on the following line, thus allowing arbitrary
indentation. The resulting value is a concatenation of the stuff before
the first \ and after the second \. You can even place a comment in
between them, for documentation purposes.


T

[Jonathan M Davis]

Post by H. S. Teoh

Post by Jonathan M Davis

Post by John Colvin
Why not YAML? It's cleaner than JSON and is very widely known.

YAML is just plain evil. It doesn't ignore whitespace.

[...]
It's funny. I used to think Python is evil for the same reason,

Well, I hate that about python too, but what I _really_ hate about python is
that it's dynamic. It shouldn't be possible to do things like change the type
of a variable based on whether an if condition was true or not (or change the
type of a variable at all for that matter). I use python at work when I need
to use a scripting language, because it's the best option that I have there,
but otherwise, I'd just use D.

Post by H. S. Teoh
But I've never used YAML, so I can't say whether or not I'd like it.

JSON is a subset of YAML 1.2, so they're very similar. Probably the most
obvious differences are that you don't need as many quotes in YAML, and
whitespace matters. I've had to deal with it some at work, and I hope to never
have to deal with it elsewhere.

- Jonathan M Davis

[H. S. Teoh]

Post by Jonathan M Davis

Post by H. S. Teoh

Post by Jonathan M Davis

Post by John Colvin
Why not YAML? It's cleaner than JSON and is very widely known.

YAML is just plain evil. It doesn't ignore whitespace.

[...]
It's funny. I used to think Python is evil for the same reason,

Well, I hate that about python too, but what I _really_ hate about
python is that it's dynamic. It shouldn't be possible to do things
like change the type of a variable based on whether an if condition
was true or not (or change the type of a variable at all for that
matter).

Yeah, this is something oft touted as being 'convenient' and 'easy', but
then in production code, you find yourself writing type checks anyway
just to make sure what's passed in is what you expect. (And things blow
up in horrible ways when some stray code passes in something with the
wrong type.) Which defeats the purpose of having a dynamic language in
the first place.

Post by Jonathan M Davis
I use python at work when I need to use a scripting language, because
it's the best option that I have there, but otherwise, I'd just use D.

Well, that's why we're here, right? :) If I were fully happy with
Python, or whatever else it is out there, I wouldn't be here in the
first place.

Post by Jonathan M Davis

Post by H. S. Teoh
But I've never used YAML, so I can't say whether or not I'd like it.

JSON is a subset of YAML 1.2, so they're very similar. Probably the
most obvious differences are that you don't need as many quotes in
YAML, and whitespace matters. I've had to deal with it some at work,
and I hope to never have to deal with it elsewhere.

[...]

Wait, how can JSON be a subset of YAML if whitespace in YAML is
significant, but it isn't in JSON?


T

[Jonathan M Davis]

Post by H. S. Teoh

Post by Jonathan M Davis
JSON is a subset of YAML 1.2, so they're very similar. Probably the
most obvious differences are that you don't need as many quotes in
YAML, and whitespace matters. I've had to deal with it some at work,
and I hope to never have to deal with it elsewhere.

[...]
Wait, how can JSON be a subset of YAML if whitespace in YAML is
significant, but it isn't in JSON?

I don't know. Maybe there's an alternate syntax in YAML that uses braces like
JSON and isn't whitespace-sensitive? I'm not enough of an expert on them to
know all of the little details. You can read what little it says on wikipedia:

https://en.wikipedia.org/wiki/YAML#JSON

But I know that whitespace matters in YAML at least some of the time, and I've
hated dealing with it.

- Jonathan M Davis

[Nick Sabalausky]

On Wed, 11 Sep 2013 13:06:05 -0700

Post by H. S. Teoh

Post by Jonathan M Davis

Post by H. S. Teoh

Post by Jonathan M Davis

Post by John Colvin
Why not YAML? It's cleaner than JSON and is very widely known.

YAML is just plain evil. It doesn't ignore whitespace.

[...]
It's funny. I used to think Python is evil for the same reason,

Well, I hate that about python too, but what I _really_ hate about
python is that it's dynamic. It shouldn't be possible to do things
like change the type of a variable based on whether an if condition
was true or not (or change the type of a variable at all for that
matter).

Yeah, this is something oft touted as being 'convenient' and 'easy',
but then in production code, you find yourself writing type checks
anyway just to make sure what's passed in is what you expect. (And
things blow up in horrible ways when some stray code passes in
something with the wrong type.) Which defeats the purpose of having a
dynamic language in the first place.

My feelings on it exactly. I also found the implicit member declarations
and its inability to match software to the correct runtime (like Java
does) to be major problems, too:
https://semitwist.com/articles/article/view/why-i-hate-python-or-any-dynamic-language-really

Post by H. S. Teoh

Post by Jonathan M Davis

Post by H. S. Teoh
But I've never used YAML, so I can't say whether or not I'd like it.

JSON is a subset of YAML 1.2, so they're very similar. Probably the
most obvious differences are that you don't need as many quotes in
YAML, and whitespace matters. I've had to deal with it some at work,
and I hope to never have to deal with it elsewhere.

[...]
Wait, how can JSON be a subset of YAML if whitespace in YAML is
significant, but it isn't in JSON?

Whitespace is only sometimes significant in YAML. On the JSON
constructs, it's not significant. On certain (all?) of the non-JSON
YAML-specific things, then it's significant.

[H. S. Teoh]

Post by Nick Sabalausky
On Wed, 11 Sep 2013 13:06:05 -0700

[...]

Post by Nick Sabalausky

Post by H. S. Teoh

Post by Jonathan M Davis
Well, I hate that about python too, but what I _really_ hate about
python is that it's dynamic. It shouldn't be possible to do things
like change the type of a variable based on whether an if
condition was true or not (or change the type of a variable at all
for that matter).

Yeah, this is something oft touted as being 'convenient' and 'easy',
but then in production code, you find yourself writing type checks
anyway just to make sure what's passed in is what you expect. (And
things blow up in horrible ways when some stray code passes in
something with the wrong type.) Which defeats the purpose of having
a dynamic language in the first place.

My feelings on it exactly. I also found the implicit member declarations
and its inability to match software to the correct runtime (like Java
https://semitwist.com/articles/article/view/why-i-hate-python-or-any-dynamic-language-really

Yeah I remember reading that. I haven't had Python blow up on me like
that (yet), but I first ran into this problem while writing some JS
code.

That was when I had to write some complex code to handle client-side
dialogues (yeah, *those* ugly things), and, in an effort to prevent the
code from becoming one long, winding spaghetti noodle, I decided to
factor out common bits into functions -- you know, typical structured
programming textbook exercise. Then things stopped working, and I
couldn't figure out why. Eventually, after many hours of hair-tearing
frustration, I found out that some stray code was passing in the wrong
object to one of the functions. But of course, the JS interpreter
couldn't care less -- there's no type system for a type mismatch to
happen, so it just barged ahead and did who knows what with that object
of the wrong type, until it tried to look up a non-existent field, which
*conveniently* returns null. This gets assigned to another field in
another object, and *then* when that other object is finally used much
later on, it gets a null dereference exception.

But this is JS we're talking about. What happens, boys and gals, when
the JS interpreter encounters an uncaught error? That's right, it logs
an error message to the error console (which is hidden by default in
most browsers), and silently fails without any warning, and then the
rest of the site's scripts (hooked to various event handlers) CONTINUE
RUNNING AS IF NOTHING HAPPENED. I'd really like to know which genius
came up with this totally dainbramaged idea, because I'd *really* like
to slap him upside the head. Can you imagine the kind of field day the
blackhats would have if, say, C code running on enterprise servers were
to blindly continue running after dereferencing a null pointer? And now
they want to put JS on the *server*? Gives me the shudders...

Seriously, this is just like writing assembly code in 1975. Screw up a
single opcode, and the computer just blindly barges onward interpreting
random bytes as instructions, wreaking havoc to your entire system while
you stare at the screen believing that it's still computing what you
think you told it to. Who knew that JS was an underhanded way of getting
people to write assembly code by hand again? :-P

Post by Nick Sabalausky

Post by H. S. Teoh

Post by Jonathan M Davis

Post by H. S. Teoh
But I've never used YAML, so I can't say whether or not I'd like it.

JSON is a subset of YAML 1.2, so they're very similar. Probably the
most obvious differences are that you don't need as many quotes in
YAML, and whitespace matters. I've had to deal with it some at work,
and I hope to never have to deal with it elsewhere.

[...]
Wait, how can JSON be a subset of YAML if whitespace in YAML is
significant, but it isn't in JSON?

Whitespace is only sometimes significant in YAML. On the JSON
constructs, it's not significant. On certain (all?) of the non-JSON
YAML-specific things, then it's significant.

Yikes. So whitespace is neither always significant nor always
insignificant, but *sometimes* significant? Then I have to agree with
Jonathan that YAML is truly evil!


T

[Nick Sabalausky]

On Wed, 11 Sep 2013 15:50:52 -0700

Post by H. S. Teoh
Seriously, this is just like writing assembly code in 1975. Screw up a
single opcode, and the computer just blindly barges onward
interpreting random bytes as instructions, wreaking havoc to your
entire system while you stare at the screen believing that it's still
computing what you think you told it to. Who knew that JS was an
underhanded way of getting people to write assembly code by hand
again? :-P

Exactly. I really do believe that's a very accurate way to put
it.

I don't like the prevailing notion that such dynamic languages have
strong typing. Yes, they *technically* have strong typing, but most
benefits are thrown right out the window. So *in effect* it's mostly
the same as not having strong typing at all - either way you're still
getting tons of seemingly random, unpredictable, barely-tracable, and
*potentially dangerous* behavior any time the slightest thing goes
wrong.

Just because a language has addressed dangerous low-level behaviors
doesn't mean it's addressed dangerous high-level behaviors. All
they've really accomplished is make the same old problems and
catastrophes operate on a higher level than before (but more slowly
and with greater power drain). So like you said: Reliability-wise,
they're just reinventing assembly.

Post by H. S. Teoh

Post by Nick Sabalausky
Whitespace is only sometimes significant in YAML. On the JSON
constructs, it's not significant. On certain (all?) of the non-JSON
YAML-specific things, then it's significant.

Yikes. So whitespace is neither always significant nor always
insignificant, but *sometimes* significant? Then I have to agree with
Jonathan that YAML is truly evil!

I don't know about evil. While I don't like indent syntax (it is one of
the things I dislike about Python), YAML does at least make it
*possible* to avoid both the syntax-fiesta of JSON and the anti-DRYness
of XML, and YAML files *can* be constructed to be very easy to read. So
I think that alone means YAML deserves at least *some* respect.

However, the problem I have with YAML is that it's complex, with various
difficult-to-remember syntaxes. I'd feel that I'd have to be very, very
careful when writing, editing or generating YAML. And yea, the
"sometimes significant indenting" is certainly part of that complexity.

Fun fact:
Did you know Python's indenting is only "sometimes significant", too?

[Jacob Carlborg]

Post by H. S. Teoh
But this is JS we're talking about. What happens, boys and gals, when
the JS interpreter encounters an uncaught error? That's right, it logs
an error message to the error console (which is hidden by default in
most browsers), and silently fails without any warning, and then the
rest of the site's scripts (hooked to various event handlers) CONTINUE
RUNNING AS IF NOTHING HAPPENED.

My experience is that if a JavaScript fails, somehow, JavaScript fill
stop working all together on the site. But that's perhaps not the case
if an exception is thrown. But rather if you're trying to use a variable
or similar that doesn't exist.

[H. S. Teoh]

Post by Jacob Carlborg

Post by H. S. Teoh
But this is JS we're talking about. What happens, boys and gals, when
the JS interpreter encounters an uncaught error? That's right, it
logs an error message to the error console (which is hidden by
default in most browsers), and silently fails without any warning,
and then the rest of the site's scripts (hooked to various event
handlers) CONTINUE RUNNING AS IF NOTHING HAPPENED.

My experience is that if a JavaScript fails, somehow, JavaScript fill
stop working all together on the site. But that's perhaps not the case
if an exception is thrown. But rather if you're trying to use a
variable or similar that doesn't exist.

[...]

Well, you may be right, but at the time I was working on a YUI-based
framework, and I discovered that either YUI, or the way the framework
initializes YUI (I didn't write the base framework code so I don't know
for sure), has some kind of default exception-catching code that catches
such exceptions and then proceeds to *ignore* it. It does terminate the
current execution thread, mind you, but all the other event handlers and
hooks are still active, and the rest of the code attached to them will
continue running despite the fact that something has catastrophically
failed. Which, of course, means that now some object(s) are in an
invalid state due to the previous failure, but the code is completely
unaware of this situation and continue barging ahead and doing stuff,
until it encounters the bad objects, and then random failures happen
(which all get swallowed by the default catcher, thus promulgating the
problem).

But either way, the behaviour is equally bad. If JS stops executing upon
encountering an exception, then you just randomly get a blank page (when
the bug is triggered) with no helpful indication whatsoever what went
wrong. If it continues executing, then you get random failures for no
apparent reason. Both are equally hard to debug, and both could've been
avoided had JS had *sane* handling of errors in the first place.


T

[Jacob Carlborg]

Post by H. S. Teoh
Well, you may be right, but at the time I was working on a YUI-based
framework, and I discovered that either YUI, or the way the framework
initializes YUI (I didn't write the base framework code so I don't know
for sure), has some kind of default exception-catching code that catches
such exceptions and then proceeds to *ignore* it. It does terminate the
current execution thread, mind you, but all the other event handlers and
hooks are still active, and the rest of the code attached to them will
continue running despite the fact that something has catastrophically
failed. Which, of course, means that now some object(s) are in an
invalid state due to the previous failure, but the code is completely
unaware of this situation and continue barging ahead and doing stuff,
until it encounters the bad objects, and then random failures happen
(which all get swallowed by the default catcher, thus promulgating the
problem).
But either way, the behaviour is equally bad. If JS stops executing upon
encountering an exception, then you just randomly get a blank page (when
the bug is triggered) with no helpful indication whatsoever what went
wrong. If it continues executing, then you get random failures for no
apparent reason. Both are equally hard to debug, and both could've been
avoided had JS had *sane* handling of errors in the first place.

Absolutely, I agree. I have seen JavaScript errors on Github from time
to time. But it seems like everything continue to work as expected.

[Russel Winder]

On Wed, 2013-09-11 at 15:17 -0400, Jonathan M Davis wrote:
[?]

Post by Jonathan M Davis
that it's dynamic. It shouldn't be possible to do things like change the type
of a variable based on whether an if condition was true or not (or change the
type of a variable at all for that matter). I use python at work when I need
to use a scripting language, because it's the best option that I have there,
but otherwise, I'd just use D.

[?]

The type of variables in Python do not change. Python is a strongly
typed language. The type of all variables is pointer to object.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130911/221aaf1b/attachment.pgp>

[H. S. Teoh]

Post by Russel Winder
[?]

Post by Jonathan M Davis
that it's dynamic. It shouldn't be possible to do things like change
the type of a variable based on whether an if condition was true or
not (or change the type of a variable at all for that matter). I use
python at work when I need to use a scripting language, because it's
the best option that I have there, but otherwise, I'd just use D.

[?]
The type of variables in Python do not change. Python is a strongly
typed language. The type of all variables is pointer to object.

[...]

That's an implementation detail. Does the Python *language* even have
such a concept as a "pointer"?

In theory, any Turing-complete language can be implemented by any other
Turing-complete language. Just because BF can be implemented in C, in no
way implies that (the C implementation of) BF is a statically-typed
language. Nor does the fact that Haskell can be implemented in C imply
that Haskell has pointers.


T

[Nick Sabalausky]

On Wed, 11 Sep 2013 22:40:30 +0100

Post by Russel Winder
[?]

Post by Jonathan M Davis
that it's dynamic. It shouldn't be possible to do things like
change the type of a variable based on whether an if condition was
true or not (or change the type of a variable at all for that
matter). I use python at work when I need to use a scripting
language, because it's the best option that I have there, but
otherwise, I'd just use D.

[?]
The type of variables in Python do not change. Python is a strongly
typed language. The type of all variables is pointer to object.

Technically, yes, but the *effect* is the same as:

int foo;
if(cond)
foo = "Whee!! This is SOOOO useful for things
*other* than generating bugs!";

[Paulo Pinto]

Post by Jonathan M Davis

Post by John Colvin
Why not YAML? It's cleaner than JSON and is very widely known.

YAML is just plain evil. It doesn't ignore whitespace.

[...]
It's funny. I used to think Python is evil for the same reason, ...

Haskell and F# are just as evil. :)

[Jonathan M Davis]

Post by Paulo Pinto

Post by Jonathan M Davis

Post by John Colvin
Why not YAML? It's cleaner than JSON and is very widely known.

YAML is just plain evil. It doesn't ignore whitespace.

[...]
It's funny. I used to think Python is evil for the same reason, ...

Haskell and F# are just as evil. :)

At least with haskell, it's generally far more straightforward due to
Haskell's function nature, and you _can_ choose to use braces and
semicolons if you want to.

- Jonathan M Davis

[Nick Sabalausky]

On Wed, 11 Sep 2013 11:04:37 -0700

Post by H. S. Teoh
As for long values, I've always disliked the fact that almost all
formats provide a way to wrap them across multiple lines, but almost
none of them let you indent the result nicely without also changing
the value. This is important for complex configuration formats that
have nested groups of settings. In my format, the syntax is
# This is a comment
value1 = "This is a very long value \
\split across multiple \
\lines."
value2 = "A short value"
module1 {
# These values are in a nested scope, so they are
# distinct from the settings above.
value1 = "This is another long \
\value split across \
\multiple lines."
value2 = "This is a value \
\with an embedded \ # a long value
\comment!"
}

SDL supports that sort of thing (except for the embedded comment,
which I agree would be kinda nice):

http://sdl.ikayzo.org/display/SDL/Language+Guide
See section "String Literals"

Your example would look like this :

# This is a comment
value1 "This is a very long value \
split across multiple \
lines."
value2 "A short value"

module1 {
# These values are in a nested scope, so they are
# distinct from the settings above.
value1 "This is another long \
value split across \
multiple lines."
}

If you want the indentation *kept*, then use backquote strings (and
omit the line continuation backslashes).

The embedded comments could be easily added, but that would take it
into "non-standard behavior" territory. (I actually had to
deliberately disallow it just to match the behavior of the reference
implementation).

[Nick Sabalausky]

On Wed, 11 Sep 2013 16:11:10 +0200

Post by John Colvin
Why not YAML? It's cleaner than JSON and is very widely known.

It often looks cleaner, but the syntax is surprisingly complicated,
and the symbols/operators can be difficult to remember.

[Paulo Pinto]

Post by Andrei Alexandrescu
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 think it is a good idea.

Even if there are rough edges, it can be improved later on based on the
community experience with it.

--
Paulo

[Brad Roberts]

How ready is it?

1) bus factor.. what happens if Sonke disappears?
2) backups?
3) scaleability?
etc?

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

[Matt Soucy]

Post by Andrei Alexandrescu
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

votes++ over here
From my usage of it, it still has a couple of things that are in
development (a bit more of a user manual would be nice but I can attempt
to make one in my "free time"), but it's in a state now where it's
definitely usable for projects.
A friend and I are planning on making a little project for a game jam
this weekend, we'll try using dub and see what happens, but so far I'd
definitely say "yes"

-Matt Soucy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130910/cb67fd58/attachment.pgp>

[luminousone]

On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei

Post by Andrei Alexandrescu
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

Not big on package repository systems for languages, The amount
of crap that eventually accumulates from abandoned projects wears
down on its usefulness.

Examples being php-pear, php-pecl, python pypi, etc I am sure
their are more examples.

Mostly however it comes down to strong policy about what stays in
the main package management system.

Projects that haven't had an update for an excessive amount of
time should likely be hidden but still available except in cases
where it is known to be unchanged without need for updates(such
as most wrappers).

And license acknowledgement, this is much more important with
source libraries then it is with say apt on Ubuntu. Accidentally
polluting a bsd project or a closed source project with LGPL/GPL
code would be very bad, And often these package management
systems obscure what the sources license actually is by simply
not showing it or informing the user.

Basically I suggest that after one year without an update a
package gets moved into a old packages list, or flagged as
hidden, Except where the author sets a flag that says the package
is a wrapper.

And when packages are fetched give a summary of the licenses
used, the license name should be enough, google can fill in the
rest if need be.

[Brad Anderson]

Post by luminousone
And license acknowledgement, this is much more important with
source libraries then it is with say apt on Ubuntu.
Accidentally
polluting a bsd project or a closed source project with LGPL/GPL
code would be very bad, And often these package management
systems obscure what the sources license actually is by simply
not showing it or informing the user.

There is a license field in the dub package file. It would be
neat if dub could warn you if it found incompatible license in
your dependencies though.

[Sönke Ludwig]

Post by luminousone
And license acknowledgement, this is much more important with
source libraries then it is with say apt on Ubuntu. Accidentally
polluting a bsd project or a closed source project with LGPL/GPL
code would be very bad, And often these package management
systems obscure what the sources license actually is by simply
not showing it or informing the user.

There is a license field in the dub package file. It would be neat if
dub could warn you if it found incompatible license in your dependencies
though.

I've added two enhancement requests for this:

https://github.com/rejectedsoftware/dub/issues/117
https://github.com/rejectedsoftware/dub-registry/issues/14

[Sönke Ludwig]

Post by luminousone
Projects that haven't had an update for an excessive amount of
time should likely be hidden but still available except in cases
where it is known to be unchanged without need for updates(such
as most wrappers).

Agreed. Maybe some other knowledge, such as how many other (active)
packages depend on it, or how often it is still downloaded, can help to
get a robust automatic measure.

[Jacob Carlborg]

Post by Sönke Ludwig
Agreed. Maybe some other knowledge, such as how many other (active)
packages depend on it, or how often it is still downloaded, can help to
get a robust automatic measure.

How many total downloads would be nice as well. In RubyGems there are
often similar packages and it can be hard to choose which to use. Example:

* bootstrap-will_paginate. 257 475 downloads

* will_paginate-bootstrap. 84 776 downloads

Obviously I'm going to choose the one with most downloads, if there are
any critical differences.

[ilya-stromberg]

On Wednesday, 11 September 2013 at 06:28:30 UTC, S?nke Ludwig

Post by Sönke Ludwig

Post by luminousone
Projects that haven't had an update for an excessive amount of
time should likely be hidden but still available except in
cases
where it is known to be unchanged without need for updates(such
as most wrappers).

Agreed. Maybe some other knowledge, such as how many other
(active) packages depend on it, or how often it is still
downloaded, can help to get a robust automatic measure.

Simple idea: try to build the package via current DMD. If
compilation false then the package too old (or we have DMD
regression). So, it would be nice to have package autotester like
for DMD/Phobos repositories.

[Faux Amis]

Post by Sönke Ludwig

Post by luminousone
Projects that haven't had an update for an excessive amount of
time should likely be hidden but still available except in cases
where it is known to be unchanged without need for updates(such
as most wrappers).

Agreed. Maybe some other knowledge, such as how many other (active)
packages depend on it, or how often it is still downloaded, can help
to get a robust automatic measure.

Simple idea: try to build the package via current DMD. If compilation
false then the package too old (or we have DMD regression). So, it would
be nice to have package autotester like for DMD/Phobos repositories.

This way it actually knows the last compatible dmd version.

[ilya-stromberg]

Post by Faux Amis

Post by ilya-stromberg
On Wednesday, 11 September 2013 at 06:28:30 UTC, S?nke Ludwig

Post by Sönke Ludwig

Post by luminousone
Projects that haven't had an update for an excessive amount
of
time should likely be hidden but still available except in
cases
where it is known to be unchanged without need for
updates(such
as most wrappers).

Agreed. Maybe some other knowledge, such as how many other
(active)
packages depend on it, or how often it is still downloaded,
can help
to get a robust automatic measure.

Simple idea: try to build the package via current DMD. If
compilation
false then the package too old (or we have DMD regression).
So, it would
be nice to have package autotester like for DMD/Phobos
repositories.

This way it actually knows the last compatible dmd version.

Yes. And list of problem packages with compilation errors or
broken dependencies.

[Jacob Carlborg]

Simple idea: try to build the package via current DMD. If compilation
false then the package too old (or we have DMD regression). So, it would
be nice to have package autotester like for DMD/Phobos repositories.

Why should you be forced to constantly use the latest DMD? That can be a
lot of work for the package developer for no gain.

[Dicebot]

On Wednesday, 11 September 2013 at 12:26:05 UTC, Jacob Carlborg

Post by Jacob Carlborg

Post by ilya-stromberg
Simple idea: try to build the package via current DMD. If
compilation
false then the package too old (or we have DMD regression).
So, it would
be nice to have package autotester like for DMD/Phobos
repositories.

Why should you be forced to constantly use the latest DMD? That
can be a lot of work for the package developer for no gain.

Because it is current D reality. Package that do not get updated
to latest front-end version are used only if there is absolutely
no other choice. Amount of inconvenience it causes to the user of
the package is tremendous.

[Jacob Carlborg]

Because it is current D reality. Package that do not get updated to
latest front-end version are used only if there is absolutely no other
choice. Amount of inconvenience it causes to the user of the package is
tremendous.

I don't understand the inconvenience. Just have multiple compilers
installed. It's not rocket science.

[Dicebot]

On Wednesday, 11 September 2013 at 20:05:18 UTC, Jacob Carlborg

Post by Jacob Carlborg

Post by Dicebot
Because it is current D reality. Package that do not get
updated to
latest front-end version are used only if there is absolutely
no other
choice. Amount of inconvenience it causes to the user of the
package is
tremendous.

I don't understand the inconvenience. Just have multiple
compilers installed. It's not rocket science.

Different front-end versions are not guaranteed to be ABI
compatible. You always need to use same compiler version within
one application and using library that is not updated to latest
version forces you to use that old version in your own code too.

[Jacob Carlborg]

Different front-end versions are not guaranteed to be ABI compatible.
You always need to use same compiler version within one application and
using library that is not updated to latest version forces you to use
that old version in your own code too.

Yes, what's the problem? That exactly what this kind of tool should be
able to handle, if needed.

[Dicebot]

On Wednesday, 11 September 2013 at 20:24:26 UTC, Jacob Carlborg

Post by Jacob Carlborg

Post by Dicebot
Different front-end versions are not guaranteed to be ABI
compatible.
You always need to use same compiler version within one
application and
using library that is not updated to latest version forces you to use
that old version in your own code too.

Yes, what's the problem? That exactly what this kind of tool
should be able to handle, if needed.

Erm, the problem is that developers always want to use latest
compiler version with all that shiny features and library that
forces him to rollback to old version must be _really_ important
to even be considered as a valid option?

[Paulo Pinto]

Post by Jacob Carlborg

Different front-end versions are not guaranteed to be ABI compatible.
You always need to use same compiler version within one application and
using library that is not updated to latest version forces you to use
that old version in your own code too.

Yes, what's the problem? That exactly what this kind of tool should be
able to handle, if needed.

Erm, the problem is that developers always want to use latest compiler
version with all that shiny features and library that forces him to
rollback to old version must be _really_ important to even be considered
as a valid option?

Not really, on my enterprise world, things move really really slowly.

Just as an example, last Friday I was helping to sort out a problem with
JBoss 4.2.2 (released on 2008).

--
Paulo

[Dicebot]

On Wednesday, 11 September 2013 at 20:34:05 UTC, Paulo Pinto

Post by Paulo Pinto
Not really, on my enterprise world, things move really really
slowly.
Just as an example, last Friday I was helping to sort out a
problem with JBoss 4.2.2 (released on 2008).

I know, had my own unpleasant encounters with enterprise world.
But it is not the case in D reality with no LTS releases.
Literally everyone is trying to use latest versions for new
projects simply because too much stuff is added with every new
version and using any old one is always personal risk.

That does not mean that package manager should not support
compiler versioning - that was an answer to Jacobs question why
library author should care about keeping it up to date with
latest frontend.

[Andrei Alexandrescu]

Post by Brad Roberts
How ready is it?
1) bus factor.. what happens if Sonke disappears?
2) backups?
3) scaleability?
etc?

The whole point of making this a community project is to improve on all
of the above. The way I see it the project should be a solid basis for
further community development.

Andrei

[Joshua Niehus]

On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei

Post by Andrei Alexandrescu
We're considering making dub the official package manager for
D. What do you all think?

This would be awesome.
+1

[Peter Williams]

Post by Andrei Alexandrescu
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?

Is there a 64 bit rpm for dub?

Peter

[Simen Kjaeraas]

Post by Andrei Alexandrescu
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?

I'm for. Glad to see this and VisualD getting more recognition.

[Nick Sabalausky]

On Tue, 10 Sep 2013 13:48:58 -0700

Post by Andrei Alexandrescu
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?

Works for me!

[Martin Nowak]

Post by Andrei Alexandrescu
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 think the package format is really good.
The registry is essential but needs to support categories, searching and
some sort of quality ranking (voting?) for future grow.
Dub itself works but is still somewhat raw.

So I am for making dub's package format and the registry the official
place for packages and supporting dub as the primary package manager.

[luminousone]

On Wednesday, 11 September 2013 at 00:18:27 UTC, Martin Nowak

Post by Martin Nowak

Post by Andrei Alexandrescu
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 think the package format is really good.
The registry is essential but needs to support categories,
searching and some sort of quality ranking (voting?) for future
grow.
Dub itself works but is still somewhat raw.
So I am for making dub's package format and the registry the
official place for packages and supporting dub as the primary
package manager.

Old, python proverb, I found 10 packages in the repo but all 11
of them are broken, or conflict with another package I am using!

[Sönke Ludwig]

Post by Martin Nowak

Post by Andrei Alexandrescu
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 think the package format is really good.
The registry is essential but needs to support categories, searching and
some sort of quality ranking (voting?) for future grow.

Full ACK, this is quite critical IMO as the raw package list already
provides less than an optimal overview. There are enhancement requests
for these in the dub-registry issue tracker [1]. If anyone wants to help
out, this is probably one of the most rewarding areas right now (I'll
eventually get to it, but things are very busy here).

[1]: https://github.com/rejectedsoftware/dub-registry/issues

[Mike Parker]

Post by Andrei Alexandrescu
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

+1

Since I started using it I've been evangelizing it quite zealously. I
would love to see this.

[ponce]

Post by Andrei Alexandrescu
We're considering making dub the official package manager for
D. What do
you all think?

Please let's do it.

At first I was like 'why would I need that?'. But soon I ported
all my (alive) projects to dub and never came back.

Since it can also generate projects for IDEs, it's also a great
simplifier of projects. I've noted that it dramatically increased
my likeliness to use and discover other's packages.

[Nathan M. Swan]

On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei

Post by Andrei Alexandrescu
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'm all in favor.

Careful about the dependencies though, particularly for
dub-registry. It's dependent on userman and vibe-d, which is
dependent on openssl, libevent, and libev (in Deimos).

NMS

[Sönke Ludwig]

Post by Nathan M. Swan

Post by Andrei Alexandrescu
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'm all in favor.
Careful about the dependencies though, particularly for dub-registry.
It's dependent on userman and vibe-d, which is dependent on openssl,
libevent, and libev (in Deimos).

That's right, at least for DUB itself, all external dependencies have
been eliminated, though (except Phobos/libcurl).

For the registry site, however, it would be impractical to remove the
vibe-d dependency (means a complete rewrite with some other dependency
used instead). But should it ever become an issue, the userman
dependency could be replaced more easily.

[Jason den Dulk]

On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei

Post by Andrei Alexandrescu
We're considering making dub the official package manager for
D. What do you all think?

I think it is a good idea. Having a broad library available for
developers to use is a big boost to productivity.

However, I agree with luminousone that there need to be some
rules about inclusion in the registry. Here are my ideas.

1) Must be legal.
2) Must be release usable.
3) Always has an active caretaker.
4) Must compile and run with a "reasonably recent" version of the
official compiler.
5) Have a clear & precise descrption of what it does.
6) Have proper licensing.

[luminousone]

On Wednesday, 11 September 2013 at 04:06:18 UTC, Jason den Dulk

Post by Brad Anderson
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei

Post by Andrei Alexandrescu
We're considering making dub the official package manager for
D. What do you all think?

I think it is a good idea. Having a broad library available for
developers to use is a big boost to productivity.
However, I agree with luminousone that there need to be some
rules about inclusion in the registry. Here are my ideas.
1) Must be legal.
2) Must be release usable.
3) Always has an active caretaker.
4) Must compile and run with a "reasonably recent" version of
the official compiler.
5) Have a clear & precise descrption of what it does.
6) Have proper licensing.

On number 4, I will point out that Derelicts opengl wrapper
defines several win32 api structs and functions that are also in
core.sys.windows.windows. Leaving me in the position of having to
maintain a change set to the wrapper in order or use it.

Don't get me wrong I love derelict, Aldacron has done one hell of
a job with it. And this complaint may have more todo with the
somewhat ambiguous status that the windowsapi wrapper and
core.sys.windows.windows and very simply what import has what
function or struct declaration, and the conflicts arising from
multiple definitions etc.

And I get it that the wrapper is more designed to work with
derelicts sdl or sfml wrappers, But this is a point that should
be brought up, their does exist libraries that will break when
used with the standard library.

I believe this would apply to point 2 and 4.

Maybe we need to define some package names that are reserved for
particular purposes, such as std, or core, or etc/etc.c/ etc...
Atleast within the context of the package manager so that
multiple packages don't use the same module name(unless of course
this is done intentionally for some useful purpose).

[Sönke Ludwig]

Post by Jason den Dulk

Post by Andrei Alexandrescu
We're considering making dub the official package manager for D. What
do you all think?

I think it is a good idea. Having a broad library available for
developers to use is a big boost to productivity.
However, I agree with luminousone that there need to be some rules about
inclusion in the registry. Here are my ideas.
1) Must be legal.
2) Must be release usable.
3) Always has an active caretaker.
5) Have a clear & precise descrption of what it does.

I think most of this would best be handled by the community using some
form of voting/commenting system (with the option for moderation in case
of 1) or by automatically fading out packages that fail certain metrics
over time (last update to long ago, to few recent downloads, too few
other packages depending on it etc.).

Post by Jason den Dulk
4) Must compile and run with a "reasonably recent" version of the
official compiler.

Having an integrated CI solution would not only solve 4, but would also
allow things such as automatic online documentation for each package.
But for so many packages this will of course be difficult in terms of
available hardware power and security issues.

Post by Jason den Dulk
6) Have proper licensing.

This should be reasonably automated by enforcing that a proper license
field is in place and enforcing proper license nesting for known license
types (see [1] and [2]).

[1]: https://github.com/rejectedsoftware/dub-registry/issues/14
[2]: https://github.com/rejectedsoftware/dub/issues/117

[Jacob Carlborg]

Post by Sönke Ludwig
Having an integrated CI solution would not only solve 4, but would also
allow things such as automatic online documentation for each package.
But for so many packages this will of course be difficult in terms of
available hardware power and security issues.

Just use Travis CI, or similar. Unfortunately Travis CI currently only
supports Linux and Mac OS X. It doesn't support multiple platforms for a
single project.

http://travis-ci.org

[Jacob Carlborg]

Post by Jason den Dulk
1) Must be legal.

What exactly does this mean in this context?

Post by Jason den Dulk
4) Must compile and run with a "reasonably recent" version of the
official compiler.

I think it's better to specify a compiler and version in the package file.

[Jason den Dulk]

On Wednesday, 11 September 2013 at 08:51:30 UTC, Jacob Carlborg

Post by Jacob Carlborg

Post by Jason den Dulk
1) Must be legal.

What exactly does this mean in this context?

You cannot include anything you do not have the legal right to
include. I.E no copyright violations, no child porn software etc.
It seems obvious, but it does need to be stated and is a standard
part of any terms and conditions related to hosting and
distribution.

Post by Jacob Carlborg

Post by Jason den Dulk
4) Must compile and run with a "reasonably recent" version of
the
official compiler.

I think it's better to specify a compiler and version in the
package file.

Yes, but if the latest version the package is known to work with
is more than 3 years old, it would be desirable to have that kept
away from the up to date packages.

[Jacob Carlborg]

Yes, but if the latest version the package is known to work with is more
than 3 years old, it would be desirable to have that kept away from the
up to date packages.

Three years is a bit different. I'm thinking more that it need to
support multiple versions of the compilers because DMD breaks code in
every single release. Why should I update a package that doesn't take
advantage of any new features or bug fixes? It's just maintenance work.

[Sönke Ludwig]

Post by Peter Williams

Post by Andrei Alexandrescu
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?

Is there a 64 bit rpm for dub?
Peter

AFAIK nobody has started to make RPM's yet (only DEB, AUR and Homebrew
so far). Manual installation is trivial though (just ./build.sh and
symlink the executable to /usr/local/bin or similar, or put it in PATH).

[Jacob Carlborg]

Post by Andrei Alexandrescu
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.

Some other minor issues:

* The registry automatically tracks the git repository. If I register a
new project it will default to "master" if no tags are available. I
would prefer to tell the registry myself what's available.

* By default a package has the target type "autodetect" which will try
and build an application and a library, as far as I understand it. Many
projects cannot be built as an application, they're just libraries. Or
the other way around.

* When running "dub init foo" you get a directory structure like this:

foo
|
|__ public
|
|__ source
| |
| |__ app.d
|
|__ views
|
|__ package.json

This directory structure is very centered around vibe.d. This was fine
when dub was primary the package manger for vibe.d, but I don't think it
should look like this if it becomes the default package manager for D. I
mean, "public" and "views", why would I need those. As I understand it
"views" can be used for string imports, in that case it would be better
to call it "res" or "resources" instead. Most non vibe.d projects would
probably not need this at all so I'm not sure if this should be default.

* Tries to be a build tool and a package manager and at same time

* I'm not sure how it installs indirect dependencies. I'm suspecting it
will always install the latest version of an indirect dependency if
nothing else is specified, which I think is really bad for systems in a
production environment. When the project is built it should locked down
and all the versions of the dependencies, including indirect dependencies.

Say I have a package file looking like this:

{
"name": "myproject",
"dependencies": {
"foo": "0.0.1"
}
}

And

{
"name": "foo",
"dependencies": {
"bar": ">= 0.0.1"
}
}

And

{
"name": "bar"
"dependencies": {
}
}

The latest version of "bar" is 0.0.1.

When building "myproject" it should lock down "bar" to the latest
version matching the requirement, that is 0.0.1.

If a new version of "bar" is out, say 0.0.2, and I'm then installing
"myproject" on a different computer, I should get the exact same
packages, that is "bar" should be at version 0.0.1.

If I want a later version of "bar" I should explicitly tell dub that.

In the end I think it's great if we get a package manager for D. But in
its current state I'm not overly enthusiastic about dub. But depending
on what other thinks and S?nke is willing to take some of this into
consideration I think it could be a good addition to the D tools.

[Sönke Ludwig]

Post by Jacob Carlborg

Post by Andrei Alexandrescu
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.

Post by Jacob Carlborg
* The registry automatically tracks the git repository. If I register a
new project it will default to "master" if no tags are available. I
would prefer to tell the registry myself what's available.

Why not _make_ a tag? But uploading zipped packages (or better
specifying an external link) could be added as an alternative without
much effort.

Post by Jacob Carlborg
* By default a package has the target type "autodetect" which will try
and build an application and a library, as far as I understand it. Many
projects cannot be built as an application, they're just libraries. Or
the other way around.

This is something that may still need some adjustments, but after all
it's just a default when there is a "source/app.d" or
"source/<packname>.d" file - an explicit "targetType": "xxx" will fix it
when it's off.

Post by Jacob Carlborg
foo
|
|__ public
|
|__ source
| |
| |__ app.d
|
|__ views
|
|__ package.json
This directory structure is very centered around vibe.d. This was fine
when dub was primary the package manger for vibe.d, but I don't think it
should look like this if it becomes the default package manager for D. I
mean, "public" and "views", why would I need those. As I understand it
"views" can be used for string imports, in that case it would be better
to call it "res" or "resources" instead. Most non vibe.d projects would
probably not need this at all so I'm not sure if this should be default.

"views" is maybe not general enough, but for what it's worth I'm also
using it on other kinds of projects (e.g. to specify GUI templates).
"res" might be a bit *too* general, but this could for sure be improved
somehow. "public" is indeed specific for web stuff, so it may be the
best to drop it by default.

I've also thought about offering a set of template projects usable for
"dub init", so that there could e.g. be a true vibe.d skeleton, but by
default it would be a minimal project with only a "source" folder.

Post by Jacob Carlborg
* Tries to be a build tool and a package manager and at same time

Note that there is "dub describe" to extract the information relevant
for actual building plus there is "dub generate xxx", so nothing is in
the way of using a separate tool for building. But having integrated
building IMO is highly convenient and keeping the build description in a
standardized format is one of the key selling points.

Post by Jacob Carlborg
* I'm not sure how it installs indirect dependencies. I'm suspecting it
will always install the latest version of an indirect dependency if
nothing else is specified, which I think is really bad for systems in a
production environment. When the project is built it should locked down
and all the versions of the dependencies, including indirect dependencies.
{
"name": "myproject",
"dependencies": {
"foo": "0.0.1"
}
}
And
{
"name": "foo",
"dependencies": {
"bar": ">= 0.0.1"
}
}
And
{
"name": "bar"
"dependencies": {
}
}
The latest version of "bar" is 0.0.1.
When building "myproject" it should lock down "bar" to the latest
version matching the requirement, that is 0.0.1.
If a new version of "bar" is out, say 0.0.2, and I'm then installing
"myproject" on a different computer, I should get the exact same
packages, that is "bar" should be at version 0.0.1.
If I want a later version of "bar" I should explicitly tell dub that.

You can put an additional "bar": "==0.0.1" dependency in the main
package to lock it to a certain version. Or, of course, just use "==" in
the bar package in the first place. This could also be implemented as a
(semi-)automatic function along the lines of "dub lock-versions" and
"dub lock-versions --upgrade".

On the other hand it's difficult to make a general statement that this
is always the best way as this may for example prevent important
security fixes to get incorporated unless the main package maintainer
releases an explicit update...

Post by Jacob Carlborg
In the end I think it's great if we get a package manager for D. But in
its current state I'm not overly enthusiastic about dub. But depending
on what other thinks and S?nke is willing to take some of this into
consideration I think it could be a good addition to the D tools.

I'm quite confident that most points are not in conflict with the
existing functionality and can be resolved just fine. Only the
build/package combination is something that is too deeply rooted in the
projects philosophy to just drop it. But it can be kept opt-out as far
as possible and shouldn't harm special use cases.

[Jacob Carlborg]

Post by Sönke Ludwig
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.

I'm thinking this type of package manager should be a development tool
as well. But there are a lot of development tools that are executables
and not just libraries. Think of your documentation generator. Without
having looked at it I would assume it's an executable. I have myself a
tool, DStep, which translate C headers to D modules. This is an
executable as well.

Post by Sönke Ludwig
Why not _make_ a tag? But uploading zipped packages (or better
specifying an external link) could be added as an alternative without
much effort.

I'm not referring to uploading zip packages. Say I have ten tags but I
only want dub to know about five of them. I want to manually say "make
the tag v0.0.1 available".

Post by Sönke Ludwig
This is something that may still need some adjustments, but after all
it's just a default when there is a "source/app.d" or
"source/<packname>.d" file - an explicit "targetType": "xxx" will fix it
when it's off.

Yes, but I still don't like the default. To avoid misunderstandings,
will the dub, by default _both_ build an executable _and_ a library. Or
will it build an executable _or_ a library?

Post by Sönke Ludwig
"views" is maybe not general enough, but for what it's worth I'm also
using it on other kinds of projects (e.g. to specify GUI templates).
"res" might be a bit *too* general, but this could for sure be improved
somehow. "public" is indeed specific for web stuff, so it may be the
best to drop it by default.

It's possible to import images, video, audio and many other type of
resources as well using string imports.

Post by Sönke Ludwig
I've also thought about offering a set of template projects usable for
"dub init", so that there could e.g. be a true vibe.d skeleton, but by
default it would be a minimal project with only a "source" folder.

Yes, I was thinking the same.

Post by Sönke Ludwig
Note that there is "dub describe" to extract the information relevant
for actual building plus there is "dub generate xxx", so nothing is in
the way of using a separate tool for building. But having integrated
building IMO is highly convenient and keeping the build description in a
standardized format is one of the key selling points.

Hmm ok. I would go with two separate tools that are well integrated with
each other.

BTW, neither "dub generate rdmd" or "dub generate build" seems to be
working.

Post by Sönke Ludwig
You can put an additional "bar": "==0.0.1" dependency in the main
package to lock it to a certain version.

I don't want to care about indirect dependencies. That's the job of the
package manager. If I need to keep track of indirect dependencies then
the package manager isn't helping much.

Post by Sönke Ludwig
Or, of course, just use "==" in the bar package in the first place.

I might only control the "myproject" package.

Post by Sönke Ludwig
This could also be implemented as a (semi-)automatic function along
the lines of "dub lock-versions" and "dub lock-versions --upgrade".

I think this should be the default. I don't want my package to break at
random just because there's a newer version available of an indirect
dependency.

I think that a key feature of a package manager should be that any time
in time you're installing a package of a given version should result in
the _exact_ same packages, including indirect packages.

Post by Sönke Ludwig
On the other hand it's difficult to make a general statement that this
is always the best way as this may for example prevent important
security fixes to get incorporated unless the main package maintainer
releases an explicit update...

Any update, may it only be security fixes, may break a build. No,
semantic versions doesn't help here. Locking down by default is the safest.

If the package maintainer doesn't release an update how will you get
security updates?

It's better if there's an explicit way to update an indirect dependency.

I would rather add "bar": "==0.0.2" on one or two packages to force an
update of an indirect dependency rather then set "bar:" "==0.0.1" on
_all_ indirect dependency. This can be quite a large tree if there are
many dependencies.

At work we have a Ruby on Rails project. It currently uses 160 packages,
including Rails and all its sub components. It was pure hell before
"bundler" was released which locks down all package dependencies as I've
described here. Counting all indirect dependencies as well I get over
413 packages. Would you like to specify the exact version of all these?

Saying that "bundler" was a salvation for the Ruby community is an
understatement.

When we get a new employee or a new computer we want, of course, to have
the _exact_ same packages we use on all the other development machines
and the ones in production. Otherwise we cannot ensure that everything
is working the same way on our development machines as on the production
machines.

Hey, just adding a new production machine we could end up with different
packages before. Pure nightmare.

[Dicebot]

On Wednesday, 11 September 2013 at 15:01:37 UTC, Jacob Carlborg

Post by Jacob Carlborg
I'm thinking this type of package manager should be a
development tool as well. But there are a lot of development
tools that are executables and not just libraries. Think of
your documentation generator. Without having looked at it I
would assume it's an executable. I have myself a tool, DStep,
which translate C headers to D modules. This is an executable
as well.

Those should be provided as sources and built by dub too.
Distributing binary packages requires both package signing and
reasonable web of trust - something that is not easy to "just
implement" from scratch. Otherwise any single malicious package
may ruin reputation of the whole system.

[Jacob Carlborg]

Those should be provided as sources and built by dub too. Distributing
binary packages requires both package signing and reasonable web of
trust - something that is not easy to "just implement" from scratch.
Otherwise any single malicious package may ruin reputation of the whole
system.

I have no problems with the packages being distributed as source. That
makes a lot of things easier. But it should compile and install it when
it's downloaded. Currently it only clones the repository. Not giving
much more than a plain "git clone".

[H. S. Teoh]

Post by Jacob Carlborg

Post by Dicebot
Those should be provided as sources and built by dub too.
Distributing binary packages requires both package signing and
reasonable web of trust - something that is not easy to "just
implement" from scratch. Otherwise any single malicious package may
ruin reputation of the whole system.

The same can be said of malicious source code. Just because it wasn't
precompiled for you doesn't mean you're going to read through every line
to ensure there are no malicious bits before compiling and using it.
Using the package at all -- regardless of whether it's source or binary
-- implies a certain level of trust already.

Post by Jacob Carlborg
I have no problems with the packages being distributed as source.
That makes a lot of things easier. But it should compile and install
it when it's downloaded. Currently it only clones the repository.
Not giving much more than a plain "git clone".

[...]

How would it know which compiler(s) to use to compile the packages? What
if you have multiple compilers / development environments with
incompatible ABIs?


T

[Jacob Carlborg]

Post by H. S. Teoh
How would it know which compiler(s) to use to compile the packages? What
if you have multiple compilers / development environments with
incompatible ABIs?

The same way it works now.

[Dicebot]

Post by H. S. Teoh

Post by Dicebot
Those should be provided as sources and built by dub too.
Distributing binary packages requires both package signing and
reasonable web of trust - something that is not easy to "just
implement" from scratch. Otherwise any single malicious
package may
ruin reputation of the whole system.

The same can be said of malicious source code. Just because it
wasn't
precompiled for you doesn't mean you're going to read through
every line
to ensure there are no malicious bits before compiling and
using it.
Using the package at all -- regardless of whether it's source
or binary
-- implies a certain level of trust already.

Source packages are never trusted by default. It is your (and
community) responsibility to verify the source if it is
important. Or just ignore the possible consequences if it is not
worth it. Contrary to this, binary package does not leave any
verification options and in absence of any package signing /
trust network one has no other choice but to always consider
those harmful.

It is subtle but important difference. As far as I am aware, all
major Linux distributions have rather complex infrastructure that
assures basic package safety. It is imperfect, of course, but any
custom system will be far far away even from that.

[Sönke Ludwig]

Post by Jacob Carlborg

Post by Sönke Ludwig
Why not _make_ a tag? But uploading zipped packages (or better
specifying an external link) could be added as an alternative without
much effort.

I'm not referring to uploading zip packages. Say I have ten tags but I
only want dub to know about five of them. I want to manually say "make
the tag v0.0.1 available".

It will only look at version tags of the form vA.B.C(postfix) any reason
to hide one of those? It could be added as a feature to the registry,
but is there a compelling use case to warrant the costs?

Post by Jacob Carlborg

Post by Sönke Ludwig
This is something that may still need some adjustments, but after all
it's just a default when there is a "source/app.d" or
"source/<packname>.d" file - an explicit "targetType": "xxx" will fix it
when it's off.

Yes, but I still don't like the default. To avoid misunderstandings,
will the dub, by default _both_ build an executable _and_ a library. Or
will it build an executable _or_ a library?

"or", you can choose which using "dub --config=library" or "dub
--config=application" (the default).

Post by Jacob Carlborg

Post by Sönke Ludwig
Note that there is "dub describe" to extract the information relevant
for actual building plus there is "dub generate xxx", so nothing is in
the way of using a separate tool for building. But having integrated
building IMO is highly convenient and keeping the build description in a
standardized format is one of the key selling points.

Hmm ok. I would go with two separate tools that are well integrated with
each other.
BTW, neither "dub generate rdmd" or "dub generate build" seems to be
working.

Works for me, but master was broken for some hours. Maybe you caught a
bad version?

Post by Jacob Carlborg

Post by Sönke Ludwig
This could also be implemented as a (semi-)automatic function along
the lines of "dub lock-versions" and "dub lock-versions --upgrade".

I think this should be the default. I don't want my package to break at
random just because there's a newer version available of an indirect
dependency.
I think that a key feature of a package manager should be that any time
in time you're installing a package of a given version should result in
the _exact_ same packages, including indirect packages.

I just don't know if that can be generalized to everyone or at least the
majority of users. Maybe this is a good topic for starting a wider
discussion/poll.

Post by Jacob Carlborg

Post by Sönke Ludwig
On the other hand it's difficult to make a general statement that this
is always the best way as this may for example prevent important
security fixes to get incorporated unless the main package maintainer
releases an explicit update...

Any update, may it only be security fixes, may break a build. No,
semantic versions doesn't help here. Locking down by default is the safest.

If used correctly, by definition, it _does_ help. Reality, especially in
the fast moving D environment, may be different, though. However it
seems to work quite well in the C world.

Post by Jacob Carlborg
If the package maintainer doesn't release an update how will you get
security updates?

By upgrading and getting updates of indirect dependencies, even if the
main package wasn't updated.

Post by Jacob Carlborg
It's better if there's an explicit way to update an indirect dependency.
I would rather add "bar": "==0.0.2" on one or two packages to force an
update of an indirect dependency rather then set "bar:" "==0.0.1" on
_all_ indirect dependency. This can be quite a large tree if there are
many dependencies.
At work we have a Ruby on Rails project. It currently uses 160 packages,
including Rails and all its sub components. It was pure hell before
"bundler" was released which locks down all package dependencies as I've
described here. Counting all indirect dependencies as well I get over
413 packages. Would you like to specify the exact version of all these?
Saying that "bundler" was a salvation for the Ruby community is an
understatement.
When we get a new employee or a new computer we want, of course, to have
the _exact_ same packages we use on all the other development machines
and the ones in production. Otherwise we cannot ensure that everything
is working the same way on our development machines as on the production
machines.
Hey, just adding a new production machine we could end up with different
packages before. Pure nightmare.

Note that I definitely don't oppose to the idea of integrating such a
mechanism -- I do see the value. The question is if it should be the
default or not (Bundler is opt-in after all), taking into account for
example how well it interacts with branches and different use cases. I'm
quite open there, but I first have to play that through with all of my
stuff before I can voice an opinion.

[Jacob Carlborg]

Post by Sönke Ludwig
It will only look at version tags of the form vA.B.C(postfix) any reason
to hide one of those? It could be added as a feature to the registry,
but is there a compelling use case to warrant the costs?

No, that should be ok.

Post by Sönke Ludwig
"or", you can choose which using "dub --config=library" or "dub
--config=application" (the default).

Ok, I see. I got confused by the documentation:

"Automatically detects the target type. This is the default global value
and causes dub to try and generate "application" and "library"
configurations"

It says '"application" and "library"'. I think you should update to say
"or" to avoid this confusion.

Post by Sönke Ludwig
Works for me, but master was broken for some hours. Maybe you caught a
bad version?

No, I don't think so, I was using 0.9.17. What's the expected
output/file(s)?

Post by Sönke Ludwig
I just don't know if that can be generalized to everyone or at least the
majority of users. Maybe this is a good topic for starting a wider
discussion/poll.

When you start using enough packages it will cause problems.

Post by Sönke Ludwig
If used correctly, by definition, it _does_ help. Reality, especially in
the fast moving D environment, may be different, though. However it
seems to work quite well in the C world.

It helps, but it won't fix or make the problem go away.

Post by Sönke Ludwig
By upgrading and getting updates of indirect dependencies, even if the
main package wasn't updated.

Then you get specify that instead in the dependency list. Most often I
don't care about indirect dependencies, as long as everything works. If
I get a new version of an indirect dependency it would be, most likely,
through a direct dependency.

Post by Sönke Ludwig
Note that I definitely don't oppose to the idea of integrating such a
mechanism -- I do see the value. The question is if it should be the
default or not (Bundler is opt-in after all), taking into account for
example how well it interacts with branches and different use cases. I'm
quite open there, but I first have to play that through with all of my
stuff before I can voice an opinion.

Bundler is required when using Ruby on Rails. I just don't want
everything to break at random just because it's a month later a new
version of a package is released.

[Brad Anderson]

On Wednesday, 11 September 2013 at 15:01:37 UTC, Jacob Carlborg

Post by Jacob Carlborg

Post by Sönke Ludwig
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.

I'm thinking this type of package manager should be a
development tool as well. But there are a lot of development
tools that are executables and not just libraries. Think of
your documentation generator. Without having looked at it I
would assume it's an executable. I have myself a tool, DStep,
which translate C headers to D modules. This is an executable
as well.

I have to completely disagree with you here. Where would it end?
Would it install vim for me? Install the Java VM so it could
run some Java tool? The level of effort needed to add this
functionality?which would duplicate dozens of existing package
management systems that already do this job well?is not worth it
(and that's before you even consider the amount of effort that
would be needed to maintain such a system).

dub handles source libraries and handles them well (for such a
young project). There is no need to make it do everything and I
think trying to would be detrimental.

[Jacob Carlborg]

I have to completely disagree with you here. Where would it end? Would
it install vim for me? Install the Java VM so it could run some Java
tool? The level of effort needed to add this functionality?which would
duplicate dozens of existing package management systems that already do
this job well?is not worth it (and that's before you even consider the
amount of effort that would be needed to maintain such a system).
dub handles source libraries and handles them well (for such a young
project). There is no need to make it do everything and I think trying
to would be detrimental.

Then we can remove all target types except for "sourceLibrary" because
they're all a lie. Currently when "installing" a executable package it
will only clone the repository. Then I have to figure out myself how to
install, which shared libraries it may depend on, which directories they
should be put in. Basically leaving the task of the package manager to
the user.

[Bruno Medeiros]

Post by Sönke Ludwig

Post by Jacob Carlborg

Post by Andrei Alexandrescu
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.

[Dicebot]

On Wednesday, 25 September 2013 at 15:51:47 UTC, Bruno Medeiros

Post by Bruno Medeiros
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

[Jacob Carlborg]

Post by Bruno Medeiros
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.

Post by Bruno Medeiros
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.

[Dicebot]

On Wednesday, 11 September 2013 at 09:57:48 UTC, Jacob Carlborg

Post by Jacob Carlborg
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.

I am strongly against it. It is not a job of language package
manager.

Implementing it properly will require to integrate the knowledge
of every existing packaging system among every slightly popular
OS / distro. Implement it as a hack with own package ecosystem
and people will hate you.

It exists to simplify development. Users that run D-based
programs should never ever be even aware of such thing as `dub`.

[Jacob Carlborg]

I am strongly against it. It is not a job of language package manager.
Implementing it properly will require to integrate the knowledge of
every existing packaging system among every slightly popular OS /
distro. Implement it as a hack with own package ecosystem and people
will hate you.
It exists to simplify development. Users that run D-based programs
should never ever be even aware of such thing as `dub`.

No, I completely agree. But there are a lot of developer tools that are
executables. They are used by developers just as dub is. It doesn't need
to be integrated with the native package manager. Just install it in a
directory and put it in the PATH.

[Joseph Rushton Wakeling]

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?

I have no direct experience of using dub, so take this as the point of view of
someone coming to it fresh and with a "What's this all about?" mindset.

Anyway, these are the general things I feel:

* Having an official package manager (and hence package repo) is a great way
to get round the current state of confusion about D libraries, with
orphaned projects in places like dsource.org etc.

In fact I think having a well-maintained one-stop shop to find actively
maintained/developed D libraries is _more_ important than having a nice
tool to install them -- but a good tool is the icing on the cake, because
it makes it easy to just grab stuff.

* It doesn't matter that much if the tool isn't perfect right now. Obviously
if S?nke has objections that matters, but otherwise, moving forward is a
good motivation for everyone to join in and fix any flaws.

* Currently I think the documentation for dub is inadequate, at least that
which was trivial for me to find. I guess that extra stuff might be
available post-install via --help or man-pages, but that material needs
to be online to read _before_ downloading and installing. Essentially I
wasn't able to get any meaningful impression of what the tool would
actually be like to use.

* Specific things I'd like to have from a docs point of view: more detailed
descriptions of how to use dub as a consumer of packages, how to handle
both user-local and system-wide install of dub packages, a clear
description of _where_ it puts user- and system-wide installed packages
(and how to customize that), how to use packages once installed (and how
to do so with different D compilers), how to update and uninstall packages.

If anyone wants to enlighten me in this thread, I'd really appreciate it
(actually some of these questions have already been answered in other
threads), but I also think that info needs to be on the dub website. :-)

At the moment I'm a bit committed to other things but I might have a go at
turning Dgraph into a dub package just to see how it goes. Should be a nice
usability test. :-)

Best wishes,

-- Joe

[Jonathan M Davis]

Post by Andrei Alexandrescu
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?

I don't know if it's quite ready for that or not, but I've started using it
for most of my stuff. It feels kind of limited to me, and I'm inclined to think
that it will need more advanced build configuration abilities in the future (it
essentially does what rdmd does, whereas some projects will need something
more along the lines of full-on make capabilities), but for basic stuff, it
works just fine.

Certainly, I have no problem with aiming for dub becoming the official package
manager, and if we think that it's ready for that now and that whatever
shortcomings it currently has can be sorted out later, then I have no problem
with it becoming the official package manager now.

- Jonathan M Davis

[Sönke Ludwig]

Post by Jonathan M Davis
I don't know if it's quite ready for that or not, but I've started using it
for most of my stuff. It feels kind of limited to me, and I'm inclined to think
that it will need more advanced build configuration abilities in the future (it
essentially does what rdmd does, whereas some projects will need something
more along the lines of full-on make capabilities), but for basic stuff, it
works just fine.

Do you have (a) concrete example(s) where things need to get more powerful?

I try to keep the surface as simple as possible while handling the
complexity mostly in the background. But of course manual control is
necessary in some places.

One thing that definitely needs some improvements is the build system
(for example building dependencies separately and caching the resulting
binaries for reuse and at some point performing proper incremental builds).

[w0rp]

I am all in favor of making dub *the* D package manager to use.
pypi is awesome, and we've got something which can be just as
awesome. Let's do it.

On the subject of YAML. I've tried it out a few times. The syntax
for JSON can be described in 1-2 pages, on json.org's front page.
The syntax for YAML requires a 50-100 page document to describe.
That should be enough to tell you not to use it.

[Jonathan M Davis]

Post by w0rp
On the subject of YAML. I've tried it out a few times. The syntax
for JSON can be described in 1-2 pages, on json.org's front page.
The syntax for YAML requires a 50-100 page document to describe.
That should be enough to tell you not to use it.

While, I agree in principle, I would point out that what's on json.org is
oversimplified and is not a valid spec. You really need to read the RFC if you
want to get it right, and that has about 9 pages of actual content:

http://www.ietf.org/rfc/rfc4627.txt?number=4627

So, you're comparing a basic explanation of JSON to a full-on spec for YAML.
Now, the YAML 1.2 spec does have about 77 pages of actual content:

http://yaml.org/spec/1.2/spec.pdf

So, you're not completely off base in your comparison (YAML _is_ way more
complicated), but to properly specify JSON requires a lot more pages than your
post indicates.

- Jonathan M Davis

[w0rp]

On Thursday, 12 September 2013 at 20:18:35 UTC, Jonathan M Davis

Post by Jonathan M Davis

Post by w0rp
On the subject of YAML. I've tried it out a few times. The
syntax
for JSON can be described in 1-2 pages, on json.org's front
page.
The syntax for YAML requires a 50-100 page document to
describe.
That should be enough to tell you not to use it.

While, I agree in principle, I would point out that what's on
json.org is
oversimplified and is not a valid spec. You really need to read
the RFC if you
want to get it right, and that has about 9 pages of actual
http://www.ietf.org/rfc/rfc4627.txt?number=4627
So, you're comparing a basic explanation of JSON to a full-on
spec for YAML.
Now, the YAML 1.2 spec does have about 77 pages of actual
http://yaml.org/spec/1.2/spec.pdf
So, you're not completely off base in your comparison (YAML
_is_ way more
complicated), but to properly specify JSON requires a lot more
pages than your
post indicates.
- Jonathan M Davis

That's a much more fair comparison. Thanks.

[deadalnix]

On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei

Post by Andrei Alexandrescu
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?

Several remarks (I'm a dub newbie, so it is mostly conditional
stuff) :
- Can we manage repositories ? For instance can I use my company
repo instead of code.dlang.org ? Can I use several repositories
with some kind of priorisation ?
- How does the tool handle several version of a package ?
- What is the process to get some code on code.dlang.org ? We
must settle something if this have to go "official".
- What is the dependance management strategy used ? How does it
resolve conflicts ?

[Sönke Ludwig]

Post by Andrei Alexandrescu
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?

- Can we manage repositories ? For instance can I use my company repo
instead of code.dlang.org ? Can I use several repositories with some
kind of priorisation ?

It supports specifying a list of registries that is searched linearly
for packages in its config file (or as a command line argument) - I
think I still need to document that, though.

The registry currently supports only GitHub and Bitbucket repositories
to source packages from, but that can be easily extended by implementing
the "Repository" interface.

- How does the tool handle several version of a package ?

In the current registry implementation, git tags of the form
vX.Y.Z[postfix] are taken as the available versions. When specifying
dependencies it's then possible to use relational operators to specify a
range of acceptable versions, of which the newest is used. Things like
the version pinning mechanism proposed by Jacob can still improve things
in this area.

- What is the process to get some code on code.dlang.org ? We must
settle something if this have to go "official".

My idea (the status quo) is to keep that as open as possible. Anyone can
register an account and register his/her repository. Package names are
reserved on a first-come-first-serve basis. This process would then be
augmented with community votes, automatic package deprecation and
sporadic moderation to keep everything clean in the long term.

- What is the dependance management strategy used ? How does it
resolve conflicts ?

There are basically three areas where things can conflict AFAICS:

- Accepted version ranges for packages that are referenced by multiple
other packages: Here the best version that satisfies all given
ranges is used if possible, otherwise error out

- Selected configuration for a package: This is resolved to the first
possible set of configurations if possible, otherwise error out
(this is a bit more complex due to the platform playing a role in
configuration selection)

- Conflicts in code (i.e. module/package name clashes) - This is
currently not handled, but there have been discussions about that
topic:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1/

[Dicebot]

Post by Sönke Ludwig

- What is the process to get some code on code.dlang.org ? We must
settle something if this have to go "official".

My idea (the status quo) is to keep that as open as possible.
Anyone can register an account and register his/her repository.
Package names are reserved on a first-come-first-serve basis.
This process would then be augmented with community votes,
automatic package deprecation and sporadic moderation to keep
everything clean in the long term.

I think AUR (Arch Linux Repository) model is very successful one
and worth paying attention to when it comes to source packages.
Other than voting it also has `out-of-date` flagging by users
which helps to noticed abandoned packages fast. There is also
small group of trusted users who processes requests for package
ownership transfer / package merging via mail list. Any
suspicious / malicious package get processed in a similar way.
Other than that it is very anarchic environment and still works
damn well - AUR package count is now more than 40 000 and Arch
Linux is pretty young distro.

[Bruno Medeiros]

Post by Andrei Alexandrescu
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??

[Jacob Carlborg]

Post by Bruno Medeiros
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.