www.digitalmars.com         C & C++   DMDScript  

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

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 10 2013
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei 
Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while 
 and things are going well. In particular Sönke has been very 
 active about maintaining and improving it, which brings further 
 confidence in the future of the project.

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


 Andrei


I 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).
Sep 10 2013
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 10 Sep 2013 23:01:12 +0200
"Brad Anderson" <eco gnuk.net> wrote:

=20
 I vote yes but only if S=F6nke feels it is ready. I suspect he has=20
 a few things he'll probably want done before this happens (the=20
 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.
Sep 10 2013
parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 10.09.2013 23:04, schrieb Nick Sabalausky:

 On Tue, 10 Sep 2013 23:01:12 +0200
 "Brad Anderson" <eco gnuk.net> wrote:

 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
Sep 10 2013
parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 11 September 2013 at 06:12:41 UTC, Sönke Ludwig 
wrote:

 Am 10.09.2013 23:04, schrieb Nick Sabalausky:

 On Tue, 10 Sep 2013 23:01:12 +0200
 "Brad Anderson" <eco gnuk.net> wrote:

 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


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.
Sep 11 2013
prev sibling parent reply Lionello Lunesu <lionello lunesu.remove.com> writes:
On 9/11/13 5:01, Brad Anderson wrote:

 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.
Sep 11 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 11 Sep 2013 21:10:46 +0800
Lionello Lunesu <lionello lunesu.remove.com> wrote:


 On 9/11/13 5:01, Brad Anderson wrote:

 I vote yes but only if S=F6nke 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).


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



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

	"dependencies": {
		"vibe-d": ">=3D0.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 ">=3D0.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.
Sep 11 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 11 September 2013 at 13:39:02 UTC, Nick Sabalausky 
wrote:

 On Wed, 11 Sep 2013 21:10:46 +0800
 Lionello Lunesu <lionello lunesu.remove.com> wrote:


 On 9/11/13 5:01, Brad Anderson wrote:

 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.


Why not YAML? It's cleaner than JSON and is very widely known.
Sep 11 2013
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 11 September 2013 at 14:11:11 UTC, John Colvin 
wrote:

 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/
Sep 11 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 11.09.2013 18:14, schrieb Brad Anderson:

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

 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/


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.
Sep 13 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-13 10:22, Sönke Ludwig wrote:


 I have to admit that looking at the examples *now* leaves me with a
 strong distaste for YAML. That wasn't the case in the beginning, but
 now, after not having looked at any YAML document since then and even
 with only the simplest syntax constructs used, it just looks confusing
 to me.

 Some points that stand out:

   - Built-in field names and user defined dictionary key (can) look the
     same and can be quite confusing (my initial reaction to the
     "sub-package:" line in the example was "Hmm.. what kind of command
     is *that*?")

   - Indentation based scoping is much less explicit than braces. Someone
     who has never seen the format may well think that it's just visual
     formatting and has to read up on it first.

   - It still has the deep nesting of the JSON format

   - The complexity of the specification is a bit of a turn-off, too

 Having said that, YAML for sure is a nice format for many things and
 considerably more powerful in some areas than f.ex. SDL, but here I
 think the focus should be on the most concise and intuitive textual
 representation and IMO SDL does a better job there. More advanced
 features of YAML, if needed, can also easily be simulated with SDL.


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

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

configurations:

   - name: console
     targetType: executable
     versions: ConsoleApp


   - 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:

   - name: console &console
     targetType: executable
     versions: ConsoleApp
     libs-windows: [gdi32, user32]


   - name: gui
     <<: *console
     versions: UseWinMain

-- 
/Jacob Carlborg
Sep 13 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 13.09.2013 14:48, schrieb Jacob Carlborg:

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

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

 configurations:

    - name: console
      targetType: executable
      versions: ConsoleApp


    - name: gui
      targetType: executable
      versions: UseWinMain
      libs-windows: [gdi32, user32]

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


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


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

 configurations:

    - name: console &console
      targetType: executable
      versions: ConsoleApp
      libs-windows: [gdi32, user32]


    - 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"
}
Sep 13 2013
parent "Martin Nowak" <code dawg.eu> writes:
On Friday, 13 September 2013 at 16:09:11 UTC, Sönke Ludwig wrote:

 Something like:

 def somevar="somevalue"
 libs "$somevar"

 or

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

 configuration "gui" {
   mixin "sometemplate"
 }


A little redundancy doesn't hurt so long as the overall package 
description remains concise and simple.
Sep 26 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/13/13, S=F6nke Ludwig <sludwig outerproduct.org> wrote:

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

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




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

libs-windows "gdi32" "user32"

To somehow use multi-line instead:

libs-windows
    "gdi32"
    "user32"

Even if we have to use the slash key for continuation (like in some
languages) it would be useful to have, since it's then easy to quickly
comment out a value by commenting out the entire line (well I have a
key shortcut to quickly comment/uncomment a line, I'd like to be able
to use it.).
Sep 13 2013
parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 13.09.2013 17:03, schrieb Andrej Mitrovic:

 On 9/13/13, Sönke Ludwig <sludwig outerproduct.org> wrote:

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

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




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

 libs-windows "gdi32" "user32"

 To somehow use multi-line instead:

 libs-windows
      "gdi32"
      "user32"

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


Both of these should work:

libs-windows \
   "gdi32" \
   "user32"

libs-windows "gdi32"
libs-windows "user32"
Sep 13 2013
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/13/13, S=F6nke Ludwig <sludwig outerproduct.org> wrote:

 Both of these should work:

 libs-windows \
    "gdi32" \
    "user32"

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


Great!
Sep 13 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:

 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
Sep 11 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:

 On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:

 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:


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

	module1 {


		value1 = "This is another long \
		         \value split across \
		         \multiple lines."
		value2 = "This is a 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

-- 
Why can't you just be a nonconformist like everyone else? -- YHL
Sep 11 2013
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 11.09.2013 20:04, schrieb H. S. Teoh:

 On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:

 On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:

 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, ...
Sep 11 2013
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, September 11, 2013 20:12:40 Paulo Pinto wrote:

 Am 11.09.2013 20:04, schrieb H. S. Teoh:

 On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:

 On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:

 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, ...


 



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
Sep 11 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 11 Sep 2013 11:04:37 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:

 
 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:
 

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


 		value1 = "This is another long \
 		         \value split across \
 		         \multiple lines."
 		value2 = "This is a 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 :


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

module1 {


	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).
Sep 11 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 11 Sep 2013 16:11:10 +0200
"John Colvin" <john.loughran.colvin gmail.com> wrote:

 
 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.
Sep 11 2013
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 10.09.2013 22:48, schrieb 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
Sep 10 2013
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
How ready is it?

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

On 9/10/13 1:48 PM, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and things are
going well. In
 particular Sönke has been very active about maintaining and improving it,
which brings further
 confidence in the future of the project.

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


 Andrei
Sep 10 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/10/13 2:16 PM, Brad Roberts wrote:

 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
Sep 10 2013
prev sibling next sibling parent Matt Soucy <msoucy csh.rit.edu> writes:
On 09/10/2013 04:48 PM, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular S=F6nke has been very active about=



 maintaining and improving it, which brings further confidence in the
 future of the project.
=20
 We're considering making dub the official package manager for D. What d=


o

 you all think?
=20
=20
 Andrei


votes++ over here
=46rom 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
Sep 10 2013
prev sibling next sibling parent reply "luminousone" <rd.hunt gmail.com> writes:
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei 
Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while 
 and things are going well. In particular Sönke has been very 
 active about maintaining and improving it, which brings further 
 confidence in the future of the project.

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


 Andrei


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.
Sep 10 2013
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 10 September 2013 at 22:06:28 UTC, luminousone wrote:

 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.
Sep 10 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 11.09.2013 00:30, schrieb Brad Anderson:

 On Tuesday, 10 September 2013 at 22:06:28 UTC, luminousone wrote:

 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
Sep 10 2013
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 11.09.2013 00:06, schrieb 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.
Sep 10 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-11 08:28, Sönke Ludwig wrote:


 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.

-- 
/Jacob Carlborg
Sep 11 2013
prev sibling parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Wednesday, 11 September 2013 at 06:28:30 UTC, Sönke Ludwig 
wrote:

 Am 11.09.2013 00:06, schrieb 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.
Sep 11 2013
next sibling parent reply Faux Amis <faux amis.com> writes:
On 11-9-2013 12:28, ilya-stromberg wrote:

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

 Am 11.09.2013 00:06, schrieb 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.
Sep 11 2013
parent "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Wednesday, 11 September 2013 at 11:31:11 UTC, Faux Amis wrote:

 On 11-9-2013 12:28, ilya-stromberg wrote:

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

 Am 11.09.2013 00:06, schrieb 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.
Sep 11 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-11 12:28, ilya-stromberg wrote:


 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.

-- 
/Jacob Carlborg
Sep 11 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 September 2013 at 12:26:05 UTC, Jacob Carlborg 
wrote:

 On 2013-09-11 12:28, ilya-stromberg wrote:


 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.
Sep 11 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-11 14:29, Dicebot wrote:


 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.

-- 
/Jacob Carlborg
Sep 11 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 September 2013 at 20:05:18 UTC, Jacob Carlborg 
wrote:

 On 2013-09-11 14:29, Dicebot wrote:


 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.
Sep 11 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-11 22:07, Dicebot wrote:


 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.

-- 
/Jacob Carlborg
Sep 11 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 September 2013 at 20:24:26 UTC, Jacob Carlborg 
wrote:

 On 2013-09-11 22:07, Dicebot wrote:


 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?
Sep 11 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 11.09.2013 22:30, schrieb Dicebot:

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

 On 2013-09-11 22:07, Dicebot wrote:


 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
Sep 11 2013
parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 September 2013 at 20:34:05 UTC, Paulo Pinto 
wrote:

 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.
Sep 11 2013
prev sibling next sibling parent "Joshua Niehus" <jm.niehus gmail.com> writes:
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei 
Alexandrescu wrote:

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


This would be awesome.
+1
Sep 10 2013
prev sibling next sibling parent reply Peter Williams <pwil3058 bigpond.net.au> writes:
On 11/09/13 06:48, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


Is there a 64 bit rpm for dub?

Peter
Sep 10 2013
parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 11.09.2013 01:17, schrieb Peter Williams:

 On 11/09/13 06:48, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


 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).
Sep 10 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-09-10, 22:48, Andrei Alexandrescu wrote:


 We've been experimenting with http://code.dlang.org for a while and  =



 things are going well. In particular S=C3=B6nke has been very active a=


bout  =


 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.

-- =

   Simen
Sep 10 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 10 Sep 2013 13:48:58 -0700
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 We've been experimenting with http://code.dlang.org for a while and=20
 things are going well. In particular S=F6nke has been very active about=20
 maintaining and improving it, which brings further confidence in the=20
 future of the project.
=20
 We're considering making dub the official package manager for D. What
 do you all think?
=20


Works for me!

https://www.youtube.com/watch?v=3DbAuPb16jRjY
Sep 10 2013
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On 09/10/2013 10:48 PM, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


 Andrei


I 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.
Sep 10 2013
next sibling parent "luminousone" <rd.hunt gmail.com> writes:
On Wednesday, 11 September 2013 at 00:18:27 UTC, Martin Nowak 
wrote:

 On 09/10/2013 10:48 PM, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a 
 while and
 things are going well. In particular Sönke has been very 
 active about
 maintaining and improving it, which brings further confidence 
 in the
 future of the project.

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


 Andrei


 I 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!
Sep 10 2013
prev sibling parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 11.09.2013 02:18, schrieb Martin Nowak:

 On 09/10/2013 10:48 PM, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


 Andrei


 I 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
Sep 10 2013
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 9/11/2013 5:48 AM, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


 Andrei


+1

Since I started using it I've been evangelizing it quite zealously. I 
would love to see this.
Sep 10 2013
parent "ponce" <contact gm3sfrommrs.fr> writes:
 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.
Sep 12 2013
prev sibling next sibling parent reply "Nathan M. Swan" <nathanmswan gmail.com> writes:
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei 
Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while 
 and things are going well. In particular Sönke has been very 
 active about maintaining and improving it, which brings further 
 confidence in the future of the project.

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


 Andrei


I'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
Sep 10 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 11.09.2013 03:49, schrieb Nathan M. Swan:

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

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


 Andrei


 I'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.
Sep 10 2013
prev sibling next sibling parent reply "Jason den Dulk" <public2 jasondendulk.com> writes:
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei 
Alexandrescu wrote:


 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.
Sep 10 2013
next sibling parent "luminousone" <rd.hunt gmail.com> writes:
On Wednesday, 11 September 2013 at 04:06:18 UTC, Jason den Dulk 
wrote:

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


 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).
Sep 10 2013
prev sibling next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 11.09.2013 06:06, schrieb Jason den Dulk:

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


 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.).


 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.


 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
Sep 10 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-11 08:56, Sönke Ludwig wrote:


 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
Sep 11 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-11 06:06, Jason den Dulk wrote:


 1) Must be legal.


What exactly does this mean in this context?


 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.

-- 
/Jacob Carlborg
Sep 11 2013
parent reply "Jason den Dulk" <public2 jasondendulk.com> writes:
On Wednesday, 11 September 2013 at 08:51:30 UTC, Jacob Carlborg 
wrote:

 On 2013-09-11 06:06, Jason den Dulk wrote:


 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.


 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.
Sep 11 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-11 13:03, Jason den Dulk wrote:


 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.

-- 
/Jacob Carlborg
Sep 11 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-10 22:48, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


Unfortunately I have to say no to its current state.

The biggest issue I have with dub is that it's really doesn't install 
packages, at least not in the traditional sense. I cannot just run "dub 
install foo" and then "foo --help". It will only clone the repository, 
not install, or install anything. It basically only supports source 
packages, which makes it mostly useless for tools/application compiling 
to executables.

I would say, compiling and installing executables is a must. It would be 
nice if it could compiling libraries as well.

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.

-- 
/Jacob Carlborg
Sep 11 2013
next sibling parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 11.09.2013 11:57, schrieb Jacob Carlborg:

 On 2013-09-10 22:48, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


 Unfortunately I have to say no to its current state.

 The biggest issue I have with dub is that it's really doesn't install
 packages, at least not in the traditional sense. I cannot just run "dub
 install foo" and then "foo --help". It will only clone the repository,
 not install, or install anything. It basically only supports source
 packages, which makes it mostly useless for tools/application compiling
 to executables.

 I would say, compiling and installing executables is a must. It would be
 nice if it could compiling libraries as well.


Right now it is a pure development tool. It would be very nice to have 
end user installs somehow supported (either by directly installing 
application packages or by generating OS specific packages such as DEB 
or RPM). But since this enters a highly operating specific area and goes 
into direct competition with the OS package manager, I think it needs a 
lot of thought and caution to be generally useful and not possibly do 
more harm than good in the end. But yes, it should be a primary goal in 
my opinion, too.


 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.


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


 * 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.


 * 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.


"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.


 * 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.


 * 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.


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...


 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.
Sep 11 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-11 13:30, Sönke Ludwig wrote:


 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.


 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".


 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?


 "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.


 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.


 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.


 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.


 Or, of course, just use "==" in the bar package in the first place.


I might only control the "myproject" package.


 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.


 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.

-- 
/Jacob Carlborg
Sep 11 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 September 2013 at 15:01:37 UTC, Jacob Carlborg 
wrote:

 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.
Sep 11 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-11 17:09, Dicebot wrote:


 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".

-- 
/Jacob Carlborg
Sep 11 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Sep 11, 2013 at 10:07:02PM +0200, Jacob Carlborg wrote:

 On 2013-09-11 17:09, Dicebot wrote:
 

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.



 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

-- 
I don't trust computers, I've spent too long programming to think that
they can get anything right. -- James Miller
Sep 11 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-11 22:15, H. S. Teoh wrote:


 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.

-- 
/Jacob Carlborg
Sep 11 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 September 2013 at 20:16:52 UTC, H. S. Teoh wrote:

 On Wed, Sep 11, 2013 at 10:07:02PM +0200, Jacob Carlborg wrote:

 On 2013-09-11 17:09, Dicebot wrote:
 

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.
Sep 11 2013
prev sibling next sibling parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 11.09.2013 17:01, schrieb Jacob Carlborg:

 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?


 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).


 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?



 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.


 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.


 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.


 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.
Sep 11 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-11 18:11, Sönke Ludwig wrote:


 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.



 "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.


 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)?


 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.



 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.



 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.


 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.

-- 
/Jacob Carlborg
Sep 11 2013
prev sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 11 September 2013 at 15:01:37 UTC, Jacob Carlborg 
wrote:

 On 2013-09-11 13:30, Sönke Ludwig wrote:


 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.
Sep 11 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-11 18:50, Brad Anderson wrote:


 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.

-- 
/Jacob Carlborg
Sep 11 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 11/09/2013 12:30, Sönke Ludwig wrote:

 Am 11.09.2013 11:57, schrieb Jacob Carlborg:

 On 2013-09-10 22:48, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


 Unfortunately I have to say no to its current state.

 The biggest issue I have with dub is that it's really doesn't install
 packages, at least not in the traditional sense. I cannot just run "dub
 install foo" and then "foo --help". It will only clone the repository,
 not install, or install anything. It basically only supports source
 packages, which makes it mostly useless for tools/application compiling
 to executables.

 I would say, compiling and installing executables is a must. It would be
 nice if it could compiling libraries as well.


 Right now it is a pure development tool. It would be very nice to have
 end user installs somehow supported (either by directly installing
 application packages or by generating OS specific packages such as DEB
 or RPM). But since this enters a highly operating specific area and goes
 into direct competition with the OS package manager, I think it needs a
 lot of thought and caution to be generally useful and not possibly do
 more harm than good in the end. But yes, it should be a primary goal in
 my opinion, too.


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

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

-- 
Bruno Medeiros - Software Engineer
Sep 25 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 25 September 2013 at 15:51:47 UTC, Bruno Medeiros 
wrote:

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

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


There is a quite extensive discussion on topic here: 
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/274/ 
(~ second half), you may want to help me push that idea :P
Sep 25 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-25 17:51, Bruno Medeiros wrote:


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


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

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

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


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


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

-- 
/Jacob Carlborg
Sep 25 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 26 September 2013 at 06:57:34 UTC, Jacob Carlborg 
wrote:

 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.


No, you just let maintainers interested in target systems to take 
care of it. And package for 2-3 you care about _personally_. It 
is an obsolete idea that developer of a library/program should do 
any packaging at all. If your program is any good, there will 
always be volunteers to adapt it nicely for their beloved systems.


 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.


Yeah and what you propose is like mandatory requirement to have a 
separate home for every single electronics vendor. Want to buy 
something from different one? You must buy new home for it, 
period. (Well, feels like we are actually going there in real 
like >_<)


 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.


This is just plain wrong. dub takes care of proper compilation of 
any tool that is contained in its registry, you don't need to do 
anything about it. But there is no possible legitimate reasons to 
install it. During development you can pretty much run in locally 
from the source dir. For end user distribution you must go 
system-specific way.


 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.


It is neither a build tool nor package manager. It is a tool that 
aggregates different possible build tools backends and takes care 
of resolving build dependencies for them. Nothing more, nothing 
less.
Sep 26 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 26 September 2013 at 11:39:50 UTC, Dicebot wrote:

 On Thursday, 26 September 2013 at 06:57:34 UTC, Jacob Carlborg 
 wrote:
 It is neither a build tool nor package manager. It is a tool 
 that aggregates different possible build tools backends and 
 takes care of resolving build dependencies for them. Nothing 
 more, nothing less.


I think, the max it should be able to do is to output .deb or 
.rpm (or .tgz) files.

After, it is the job the standard install mechanism on the host 
OS.
Sep 26 2013
parent reply "eles" <eles eles.com> writes:
On Thursday, 26 September 2013 at 12:12:04 UTC, eles wrote:

 On Thursday, 26 September 2013 at 11:39:50 UTC, Dicebot wrote:

 On Thursday, 26 September 2013 at 06:57:34 UTC, Jacob Carlborg 
 wrote:
 It is neither a build tool nor package manager. It is a tool




While speaking about the dub, somebode with edit rights could 
take care of this little glitch?

On the page:

http://code.dlang.org/download

The link in:

"Debian packages are available as part of Jordi Sayol's D APT 
repository."

should be updated from:

https://code.google.com/p/d-apt/wiki/APT_Repository

to:

http://d-apt.sourceforge.net/
Sep 26 2013
parent "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 26 September 2013 at 12:14:42 UTC, eles wrote:

 On Thursday, 26 September 2013 at 12:12:04 UTC, eles wrote:

 On Thursday, 26 September 2013 at 11:39:50 UTC, Dicebot wrote:

 On Thursday, 26 September 2013 at 06:57:34 UTC, Jacob 
 Carlborg wrote:
 It is neither a build tool nor package manager. It is a tool




 While speaking about the dub, somebode with edit rights could 
 take care of this little glitch?

 On the page:

 http://code.dlang.org/download

 The link in:

 "Debian packages are available as part of Jordi Sayol's D APT 
 repository."

 should be updated from:

 https://code.google.com/p/d-apt/wiki/APT_Repository

 to:

 http://d-apt.sourceforge.net/


It'll be fixed once Sönke merges this: 
https://github.com/rejectedsoftware/dub-registry/pull/16
Sep 26 2013
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 26/09/2013 12:39, Dicebot wrote:

 During development you can pretty much run in locally from the source
 dir. For end user distribution you must go system-specific way.


To be fair, I don't entirely agree with this. End user 
distribution/installation doesn't have to be system-specific. I can see 
many interesting and useful use-cases for a cross-platform user 
application package manager. It might be a real cool project if done 
properly.
I just don't think dub should aim for that goal. It should mainly be a 
build tool and package manager for development-time usage.

-- 
Bruno Medeiros - Software Engineer
Sep 26 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 26 September 2013 at 14:20:53 UTC, Bruno Medeiros 
wrote:

 On 26/09/2013 12:39, Dicebot wrote:

 During development you can pretty much run in locally from the 
 source
 dir. For end user distribution you must go system-specific way.


 To be fair, I don't entirely agree with this. End user 
 distribution/installation doesn't have to be system-specific. I 
 can see many interesting and useful use-cases for a 
 cross-platform user application package manager. It might be a 
 real cool project if done properly.
 I just don't think dub should aim for that goal. It should 
 mainly be a build tool and package manager for development-time 
 usage.


I mean that it must respect rules and guidelines of target 
system. It is entirely possible to abstract lot of details away, 
there is a PackageKit for example it it does work pretty good. 
But it works by incorporating knowledge of all specific package 
managers and quirks inside, something I don't think we want to 
spend time on in dub.
Sep 26 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, September 26, 2013 15:20:53 Bruno Medeiros wrote:

 I just don't think dub should aim for that goal. It should mainly be a
 build tool and package manager for development-time usage.


Agreed. I don't think that dub should have anything to with installing 
programs or installing anything in the system at large. IMHO, it should be 
solely for development. At most, it should be set up to collect all of the 
libraries needed for running the application so that you know what you need 
when actually creating a system package for your application.

- Jonathan M Davis
Sep 26 2013
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 26 September 2013 at 14:20:53 UTC, Bruno Medeiros 
wrote:

 To be fair, I don't entirely agree with this. End user 
 distribution/installation doesn't have to be system-specific. I 
 can see many interesting and useful use-cases for a 
 cross-platform user application package manager. It might be a 
 real cool project if done properly.


That's CPAN.  You just described CPAN.  It supports both system 
and user level package installing, bails properly when build deps 
are missing, and has enough metadata that we can support it from 
the system package manager for proper system-level depgraph and 
file tracking.  If there's a wheel we want to steal or reinvent, 
this is THE one.

But I think it's important to remember it would be complete cat 
puke like ruby packaging if they didn't have PAUSE [0]; clear, 
moderately-strict submission guidelines [1] (especially for 
newcomers); and PrePAN, for feedback and discussion BEFORE it 
goes up.

The latter, and community involvement in general, is possibly the 
most important aspect of this process because the community is 
ultimately your userbase. (It's not so knock-down/drag-out as 
Phobos module reviews, but it's a great source of sanity 
checking.[2])

-Wyatt

[0] http://www.cpan.org/modules/04pause.html Recommend reading 
the whole thing.
[1] http://search.cpan.org/~rjbs/perl-5.18.1/pod/perlnewmod.pod
[2] http://prepan.org/module/nXWJ8Y9sBtw A good recent example
Sep 27 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 27 September 2013 at 13:00:58 UTC, Wyatt wrote:

 ...


afaik CPAN mixes development packages and distribution packages 
too, which I doubt is desired.

It may be unfortunate consequence of Perl interpreted nature 
though.
Sep 27 2013
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 27 September 2013 at 13:03:20 UTC, Dicebot wrote:

 On Friday, 27 September 2013 at 13:00:58 UTC, Wyatt wrote:

 ...


 afaik CPAN mixes development packages and distribution packages 
 too, which I doubt is desired.

 It may be unfortunate consequence of Perl interpreted nature 
 though.


Unless we're talking about different things, that's denoted in 
the META.json (I don't recall if the distinction existed in the 
META.yaml era) with e.g.
     "release_status" : "stable",
or
     "release_status" : "testing",

A proper tool can (and will) filter for this by default.

And to be explicitly clear, I'm not saying it's perfect for us 
as-is (or even perfect in general).  They're just the model 
citizen to take after.

-Wyatt
Sep 27 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 27 September 2013 at 13:29:26 UTC, Wyatt wrote:

 Unless we're talking about different things, that's denoted in 
 the META.json (I don't recall if the distinction existed in the 
 META.yaml era) with e.g.
     "release_status" : "stable",
 or
     "release_status" : "testing",


No, I mean that it does not make any difference between "programs 
written in perl to be widely used" and "libraries / tools for 
development in perl". For interpreted languages this distinction 
hardly makes sense, but for natively compiled ones it is pretty 
important.

And that was kind of the core point of the argument - can 
language-specific package manager be allowed to manage the 
former? I stand by the point that is a bad practice to provide 
any functionality that allows it, Jacob has opposite point of 
view :)
Sep 27 2013
parent "Wyatt" <wyatt.epp gmail.com> writes:
Funny, I started this with a clear mindset, but it ended up more 
nuanced than I expected.

On Friday, 27 September 2013 at 13:43:59 UTC, Dicebot wrote:

 No, I mean that it does not make any difference between 
 "programs written in perl to be widely used" and "libraries / 
 tools for development in perl". For interpreted languages this 
 distinction hardly makes sense, but for natively compiled ones 
 it is pretty important.


That's true, though at some level I wonder if its continued 
prevalence more comes back to CPAN supporting system and 
local-to-user installation simultaneously.  Users have been 
adding ~/bin to their $PATH since $EPOCH.


 And that was kind of the core point of the argument - can 
 language-specific package manager be allowed to manage the 
 former?


Not at the system level, it probably shouldn't.  Ideally, binary 
executables and libraries are the exclusive demesne of the system 
package manager.

As a historical footnote, I suspect part of why CPAN works the 
way it does is it was designed and (I think) released before RPM 
was even written. (It may even predate the original dpkg.)  More 
important than long precedent, though: Perl is largely 
self-contained by default, and can be made completely so [0].

In some sense, I _like_ the idea of installing module source to 
e.g. /usr/lib64/d2/site_d/2.63/ as long as dub is built into a 
normal install (control env with a config file in ~) and let it 
update the user's dmd.conf as a value-add [1].


 I stand by the point that is a bad practice to provide any 
 functionality that allows it, Jacob has opposite point of view 
 :)


I... turns out I have mixed feelings on this.  In the general 
sense, I'm strongly inclined to agree with you.  External package 
management undermines the sysadmin's ability to make good package 
installation decisions, splits the system dependency graph, and 
can create file conflicts.

But on the other hand, as long as there are sufficient options 
(preferable), a utility, or an API to interrogate dub for 
complete useful metadata; I'll refrain from getting too vehement 
about it.  This is only because that means system package 
managers _can_ properly integrate it, should they choose to do 
so. (cf. g-cpan [2])

See, I have my standards as a sysadmin, but don't forget policy 
victims, either: many others are stuck dealing with a CErtaiN 
Terrible Old diStribution and would probably appreciate a tool 
that isn't stuck mired in Really HorriblE poLicy when they're 
trying to get work done. [3]

My breaking point is actually the idea of using dub to call the 
system package manager, which I still think is a Really Bad Idea. 
[4]

-Wyatt

[0] Consider the output of perl '-V:.*site.*' and the existence 
of Perlbrew (http://perlbrew.pl/)
[1] As a tangent, a nice separate utility to have might be 
something like a "dub-config" to help with module paths and maybe 
linkage (In the vein of all those /usr/bin/*-config things).  
Like so: dmd `dub-config --moddir vibed` thisLinksVibe.d.
[2] http://www.gentoo.org/proj/en/perl/g-cpan.xml
[3] Yes, juvenile RHELL potshots make me feel a little better 
about my situation.
[4] https://github.com/rejectedsoftware/dub/issues/52
Sep 27 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 27/09/2013 14:00, Wyatt wrote:

 On Thursday, 26 September 2013 at 14:20:53 UTC, Bruno Medeiros wrote:

 To be fair, I don't entirely agree with this. End user
 distribution/installation doesn't have to be system-specific. I can
 see many interesting and useful use-cases for a cross-platform user
 application package manager. It might be a real cool project if done
 properly.


 That's CPAN.  You just described CPAN.  It supports both system and user
 level package installing, bails properly when build deps are missing,
 and has enough metadata that we can support it from the system package
 manager for proper system-level depgraph and file tracking.  If there's
 a wheel we want to steal or reinvent, this is THE one.

 But I think it's important to remember it would be complete cat puke
 like ruby packaging if they didn't have PAUSE [0]; clear,
 moderately-strict submission guidelines [1] (especially for newcomers);
 and PrePAN, for feedback and discussion BEFORE it goes up.

 The latter, and community involvement in general, is possibly the most
 important aspect of this process because the community is ultimately
 your userbase. (It's not so knock-down/drag-out as Phobos module
 reviews, but it's a great source of sanity checking.[2])

 -Wyatt

 [0] http://www.cpan.org/modules/04pause.html Recommend reading the whole
 thing.
 [1] http://search.cpan.org/~rjbs/perl-5.18.1/pod/perlnewmod.pod
 [2] http://prepan.org/module/nXWJ8Y9sBtw A good recent example


I would only consider a cross-platform user application package manager 
to be interesting (that is, useful to a significant level) if it's not 
tied to any particular language (or platform).

-- 
Bruno Medeiros - Software Engineer
Oct 08 2013
parent "Wyatt" <wyatt.epp gmail.com> writes:
On Tuesday, 8 October 2013 at 10:18:03 UTC, Bruno Medeiros wrote:

 I would only consider a cross-platform user application package 
 manager to be interesting (that is, useful to a significant 
 level) if it's not tied to any particular language (or 
 platform).


...Oh, you're looking for Gentoo Prefix.  Got it.  Here you go: 
http://www.gentoo.org/proj/en/gentoo-alt/prefix/ :)

-Wyatt
Oct 08 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-26 13:39, Dicebot wrote:


 No, you just let maintainers interested in target systems to take care
 of it. And package for 2-3 you care about _personally_. It is an
 obsolete idea that developer of a library/program should do any
 packaging at all. If your program is any good, there will always be
 volunteers to adapt it nicely for their beloved systems.


Most developers/packagers/people don't even know about D. They know even 
less about my projects. Be realistic.


 Yeah and what you propose is like mandatory requirement to have a
 separate home for every single electronics vendor. Want to buy something
 from different one? You must buy new home for it, period. (Well, feels
 like we are actually going there in real like >_<)


I'm just being realistic. Most of these packages won't ever end up in a 
system package manager.


 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.


 This is just plain wrong. dub takes care of proper compilation of any
 tool that is contained in its registry, you don't need to do anything
 about it.


It does _not_ compile packages using "dub install". At least not the one 
I created. Yes, it could compile it without any problem. It just doesn't 
do that when you run "dub install".


 But there is no possible legitimate reasons to install it.
 During development you can pretty much run in locally from the source
 dir. For end user distribution you must go system-specific way.





 It is neither a build tool nor package manager. It is a tool that
 aggregates different possible build tools backends and takes care of
 resolving build dependencies for them. Nothing more, nothing less.


It advertise itself as a package manager.

-- 
/Jacob Carlborg
Sep 26 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-26 13:39, Dicebot wrote:


 No, you just let maintainers interested in target systems to take care
 of it. And package for 2-3 you care about _personally_. It is an
 obsolete idea that developer of a library/program should do any
 packaging at all. If your program is any good, there will always be
 volunteers to adapt it nicely for their beloved systems.


How about doing a compromise. We add a new command to "dub" which will 
execute an installed package. Something like this:

$ dub install foo
$ dub exec foo --help

This will by default look in the package.json file, in the current 
working directory, if it exists, for the correct version of the package 
to run.

-- 
/Jacob Carlborg
Sep 26 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 27 September 2013 at 06:49:39 UTC, Jacob Carlborg 
wrote:

 On 2013-09-26 13:39, Dicebot wrote:


 No, you just let maintainers interested in target systems to 
 take care
 of it. And package for 2-3 you care about _personally_. It is 
 an
 obsolete idea that developer of a library/program should do any
 packaging at all. If your program is any good, there will 
 always be
 volunteers to adapt it nicely for their beloved systems.


 How about doing a compromise. We add a new command to "dub" 
 which will execute an installed package. Something like this:

 $ dub install foo
 $ dub exec foo --help

 This will by default look in the package.json file, in the 
 current working directory, if it exists, for the correct 
 version of the package to run.


Ok, this is pretty hygienic (though as I have said it makes more 
sense to call it `dub cache` instead of `dub install`). Though 
what does it give you over just providing same environment via 
build dependencies? (I know, dub does not seem to build binaries 
from dependencies right now but I got an impression this is going 
to be fixed)
Sep 27 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-27 09:08, Dicebot wrote:


 Ok, this is pretty hygienic (though as I have said it makes more sense
 to call it `dub cache` instead of `dub install`).


Currently "cache" is probably a better name. But if binaries are 
compiled I think "install" is an ok name. It just doesn't install it in 
the usual locations.


 Though what does it give you over just providing same environment via build
dependencies?


I'm not sure what you mean.


 (I know, dub does not seem to build binaries from dependencies right now
 but I got an impression this is going to be fixed)


Again, I'm not sure what you mean by "from dependencies". It doesn't 
build binaries at all.

Preferably I would like to be able to use "dub install/cache" and "dub 
exec" regardless if I have a project/package.json or not.

-- 
/Jacob Carlborg
Sep 27 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 27 September 2013 at 07:32:12 UTC, Jacob Carlborg 
wrote:

 On 2013-09-27 09:08, Dicebot wrote:


 Ok, this is pretty hygienic (though as I have said it makes 
 more sense
 to call it `dub cache` instead of `dub install`).


 Currently "cache" is probably a better name. But if binaries 
 are compiled I think "install" is an ok name. It just doesn't 
 install it in the usual locations.


It won't install it out of clone dir either in that mode. Why 
would it? Building is enough.


 Though what does it give you over just providing same 
 environment via build dependencies?


 I'm not sure what you mean.


Currently you can define dependencies in your package.json to 
other dub packages. Those will be in your -I flags when building. 
I expect this to be also extended to -L and PATH, so that you can 
call any binaries from dependency packages as if they were 
installed (during build/test of your package). For this to work 
no real installation is needed, just building packages straight 
in the clone dir and keeping it.
Sep 27 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-27 10:05, Dicebot wrote:


 It won't install it out of clone dir either in that mode. Why would it?
 Building is enough.


I'm not going to argue the semantics of "install". But yes, building is 
enough for that command.


 Currently you can define dependencies in your package.json to other dub
 packages. Those will be in your -I flags when building. I expect this to
 be also extended to -L and PATH, so that you can call any binaries from
 dependency packages as if they were installed (during build/test of your
 package). For this to work no real installation is needed, just building
 packages straight in the clone dir and keeping it.


If that's supported then "dub exec" won't give any advantage. But since 
that's currently isn't supported I suggested the "dub exec" command.

Unless "dub exec" can be used without a package.json file. That would 
work with packages you previously run "dub install" for.

-- 
/Jacob Carlborg
Sep 27 2013
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 27 September 2013 at 11:50:28 UTC, Jacob Carlborg 
wrote:

 If that's supported then "dub exec" won't give any advantage. 
 But since that's currently isn't supported I suggested the "dub 
 exec" command.


I am pretty sure everyone has agreed it should be supported in 
the long run (and implementation effort is roughly the same as 
for `dub exec`). It naturally fits with current dub concept and 
mode of operations.

Don't exactly know what are Sonke plans about it though.
Sep 27 2013
prev sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Friday, 27 September 2013 at 06:49:39 UTC, Jacob Carlborg 
wrote:

 On 2013-09-26 13:39, Dicebot wrote:


 No, you just let maintainers interested in target systems to 
 take care
 of it. And package for 2-3 you care about _personally_. It is 
 an
 obsolete idea that developer of a library/program should do any
 packaging at all. If your program is any good, there will 
 always be
 volunteers to adapt it nicely for their beloved systems.


 How about doing a compromise. We add a new command to "dub" 
 which will execute an installed package. Something like this:

 $ dub install foo
 $ dub exec foo --help

 This will by default look in the package.json file, in the 
 current working directory, if it exists, for the correct 
 version of the package to run.


I like the idea of a dub exec for when there is a tool you want 
to make use of during development.  Keeps everything nice and 
tidy and doesn't pretend to be an OS package manager.

+1
Oct 11 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 26/09/2013 07:57, Jacob Carlborg wrote:

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

 I have to figure out myself how to compile and install the tool. It's only
half way there.


You have to install the yourself, yes. Not compile it. Dub should take 
care of the compiling aspect.
If you just want to use the tool executable artifact, dub is likely not 
right for you. If the tool requires more complex installation, the tool 
developers should provide their own installer or OS distribution package.



 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.


A build tool should not download anything? That is antiquated C/C++/make 
way of thinking. Popular build tools for modern languages all do 
downloading, for example Apache Maven (for Java), Gradle (for lots of 
different languages), and even RubyGems.
You might say RubyGems is a package manager, and not a build tool. But 
in practice it is both actually, even if it is not called a build tool: 
It fullfills the the equivalent goal as structured build tools like 
Maven or Graddle do for other language, the distinction is only less 
clear becase Ruby as a language can be easily interpreted and does 
require an overt "compilation/build" phase to generate an executable.

-- 
Bruno Medeiros - Software Engineer
Sep 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-26 15:53, Bruno Medeiros wrote:


 You have to install the yourself, yes. Not compile it. Dub should take
 care of the compiling aspect.


Have you tried it? It does _not_ compile a package when running "dub 
install".


 If you just want to use the tool executable artifact, dub is likely not
 right for you.


That might be the case. I'm just seeing this as a great opportunity to 
use libraries and tools for development.


 If the tool requires more complex installation, the tool
 developers should provide their own installer or OS distribution package.




 A build tool should not download anything? That is antiquated C/C++/make
 way of thinking. Popular build tools for modern languages all do
 downloading, for example Apache Maven (for Java), Gradle (for lots of
 different languages), and even RubyGems.


I just think that should be a separate tool.


 You might say RubyGems is a package manager, and not a build tool. But
 in practice it is both actually, even if it is not called a build tool:
 It fullfills the the equivalent goal as structured build tools like
 Maven or Graddle do for other language, the distinction is only less
 clear becase Ruby as a language can be easily interpreted and does
 require an overt "compilation/build" phase to generate an executable.



-- 
/Jacob Carlborg
Sep 26 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 26/09/2013 20:52, Jacob Carlborg wrote:

 You have to install the yourself, yes. Not compile it. Dub should take
 care of the compiling aspect.


 Have you tried it? It does _not_ compile a package when running "dub
 install".


It compiles packages when used as dependencies in another package, and 
run with the "dub build" command.

What perhaps you meant to say is that dub doesn't compile application 
packages that it downloads from the registry. That might be true. Even 
so, if you do "dub install" of one such package, then navigate to the 
directory where it was installed, and do "dub build", it should compile 
the executable. I haven't tried that myself though.

-- 
Bruno Medeiros - Software Engineer
Sep 27 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-27 13:22, Bruno Medeiros wrote:


 It compiles packages when used as dependencies in another package, and
 run with the "dub build" command.

 What perhaps you meant to say is that dub doesn't compile application
 packages that it downloads from the registry. That might be true. Even
 so, if you do "dub install" of one such package, then navigate to the
 directory where it was installed, and do "dub build", it should compile
 the executable. I haven't tried that myself though.


Yes, it does. But that's where I draw the line with the "dub install" 
command actually installs or not. So since it doesn't build the package 
I wouldn't considered the package installed, which is what I expect from 
a command named "install". But what you already have said "cache" sounds 
like a better name for what it currently does.

-- 
/Jacob Carlborg
Sep 27 2013
parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 27/09/2013 12:53, Jacob Carlborg wrote:

 On 2013-09-27 13:22, Bruno Medeiros wrote:


 It compiles packages when used as dependencies in another package, and
 run with the "dub build" command.

 What perhaps you meant to say is that dub doesn't compile application
 packages that it downloads from the registry. That might be true. Even
 so, if you do "dub install" of one such package, then navigate to the
 directory where it was installed, and do "dub build", it should compile
 the executable. I haven't tried that myself though.


 Yes, it does. But that's where I draw the line with the "dub install"
 command actually installs or not. So since it doesn't build the package
 I wouldn't considered the package installed, which is what I expect from
 a command named "install". But what you already have said "cache" sounds
 like a better name for what it currently does.


"mirror" would also be a good name for what it currently does. But 
personally I'm not that bothered about "install".

-- 
Bruno Medeiros - Software Engineer
Oct 04 2013
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 11 September 2013 at 09:57:48 UTC, Jacob Carlborg 
wrote:

 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`.
Sep 11 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-11 14:33, Dicebot wrote:


 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.

-- 
/Jacob Carlborg
Sep 11 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 10/09/13 22:48, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and things are
 going well. In particular Sönke has been very active about maintaining and
 improving it, which brings further confidence in the future of the project.

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


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
Sep 11 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, September 11, 2013 11:04:37 H. S. Teoh wrote:

 On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:

 On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:

 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.


 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
Sep 11 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, September 10, 2013 13:48:58 Andrei Alexandrescu wrote:

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


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
Sep 11 2013
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 11.09.2013 21:20, schrieb 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).
Sep 11 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Sep 11, 2013 at 03:17:22PM -0400, Jonathan M Davis wrote:

 On Wednesday, September 11, 2013 11:04:37 H. S. Teoh wrote:

 On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:

 On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:

 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.



 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.



 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

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
Sep 11 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 11 Sep 2013 13:06:05 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:


 On Wed, Sep 11, 2013 at 03:17:22PM -0400, Jonathan M Davis wrote:

 On Wednesday, September 11, 2013 11:04:37 H. S. Teoh wrote:

 On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:

 On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:

 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


 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.
Sep 11 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Sep 11, 2013 at 05:11:38PM -0400, Nick Sabalausky wrote:

 On Wed, 11 Sep 2013 13:06:05 -0700
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:
 

 On Wed, Sep 11, 2013 at 03:17:22PM -0400, Jonathan M Davis wrote:




[...]

 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


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




 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

-- 
All problems are easy in retrospect.
Sep 11 2013
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 11 Sep 2013 15:50:52 -0700
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:


 On Wed, Sep 11, 2013 at 05:11:38PM -0400, Nick Sabalausky wrote:
 
 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.


 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?
Sep 11 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-12 00:50, H. S. Teoh wrote:


 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.

-- 
/Jacob Carlborg
Sep 11 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 12, 2013 at 08:39:11AM +0200, Jacob Carlborg wrote:

 On 2013-09-12 00:50, H. S. Teoh wrote:
 

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

-- 
Gone Chopin. Bach in a minuet.
Sep 12 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-12 15:37, H. S. Teoh wrote:


 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.

-- 
/Jacob Carlborg
Sep 12 2013
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2013-09-11 at 15:17 -0400, Jonathan M Davis wrote:
[=E2=80=A6]

 that it's dynamic. It shouldn't be possible to do things like change the =


type=20

 of a variable based on whether an if condition was true or not (or change=


 the=20

 type of a variable at all for that matter). I use python at work when I n=


eed=20

 to use a scripting language, because it's the best option that I have the=


re,=20

 but otherwise, I'd just use D.


[=E2=80=A6]

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

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 11 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 11 Sep 2013 22:40:30 +0100
Russel Winder <russel winder.org.uk> wrote:


 On Wed, 2013-09-11 at 15:17 -0400, Jonathan M Davis wrote:
 [=E2=80=A6]

 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.


 [=E2=80=A6]
=20
 The type of variables in Python do not change. Python is a strongly
 typed language. The type of all variables is pointer to object.
=20


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

int foo;
if(cond)
	foo =3D "Whee!! This is SOOOO useful for things
	*other* than generating bugs!";
Sep 11 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, September 11, 2013 13:06:05 H. S. Teoh wrote:

 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
Sep 11 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Sep 11, 2013 at 10:40:30PM +0100, Russel Winder wrote:

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

 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

-- 
"I suspect the best way to deal with procrastination is to put off the
procrastination itself until later. I've been meaning to try this, but
haven't gotten around to it yet. " -- swr
Sep 11 2013
prev sibling next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
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.
Sep 12 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, September 12, 2013 22:02:15 w0rp wrote:

 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
Sep 12 2013
parent "w0rp" <devw0rp gmail.com> writes:
On Thursday, 12 September 2013 at 20:18:35 UTC, Jonathan M Davis
wrote:

 On Thursday, September 12, 2013 22:02:15 w0rp wrote:

 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


That's a much more fair comparison. Thanks.
Sep 13 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei 
Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while 
 and things are going well. In particular Sönke has been very 
 active about maintaining and improving it, which brings further 
 confidence in the future of the project.

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


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 ?
Sep 13 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 13.09.2013 12:00, schrieb deadalnix:

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

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


 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 ?


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/
Sep 13 2013
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 13 September 2013 at 11:55:42 UTC, Sönke Ludwig wrote:

  - 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.
Sep 13 2013
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 10/09/2013 21:48, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


 Andrei


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

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

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

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


-- 
Bruno Medeiros - Software Engineer
Sep 25 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-25 18:14, Bruno Medeiros wrote:


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


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

-- 
/Jacob Carlborg
Sep 25 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 26 September 2013 at 06:59:05 UTC, Jacob Carlborg 
wrote:

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


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


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


Install packages: yes, but locally, primarily for dub/development 
use. Not system-level library installations for end-users.

I think when people are talking about not wanting it to install 
things they are talking about the latter, not the former.
Sep 26 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 26 September 2013 at 10:18:07 UTC, John Colvin wrote:

 Install packages: yes, but locally, primarily for 
 dub/development use. Not system-level library installations for 
 end-users.

 I think when people are talking about not wanting it to install 
 things they are talking about the latter, not the former.


I am against even user-wide installation. It should provide 
environment for building other dub packages, not interfere with 
normal way system operates. Lot of developers are terrible at 
packaging and once you provide even limited tool to do it "dirty" 
way it will be forced on users. This has already made ruby 
projects unusable for anyone but ruby developers, I don't want 
this for D.

AFAIK currently `dub install` does hardly anything more than just 
cloning matching repository and remembering it in local registry. 
`dub cache` would have been probably better name. And `dub 
install --system` should really just be deprecated as very bad 
practice.
Sep 26 2013
prev sibling parent "eles" <eles eles.com> writes:
On Thursday, 26 September 2013 at 10:18:07 UTC, John Colvin wrote:

 On Thursday, 26 September 2013 at 06:59:05 UTC, Jacob Carlborg 
 wrote:

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


 Install packages: yes, but locally, primarily for 
 dub/development use. Not system-level library installations for 
 end-users.

 I think when people are talking about not wanting it to install 
 things they are talking about the latter, not the former.


I feel that, in order for this behaviour to be truly local to the 
compiler and OS-independent, that the interface between the 
compiler and dub is required, to inform the former about the 
existence of these packages.

Currently, this is a compiler-by-compiler approach but, if 
standardized, it will kinda go into language/compiler specs.
Sep 26 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 26 September 2013 at 06:59:05 UTC, Jacob Carlborg 
wrote:

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


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


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


Good look getting all those small trivial libraries into official 
repositories. Actually, some distros even prohibit pure source 
packages at all.

You should install it because you are tired of satisfying build 
dependencies manually and it is a bit more robust than git 
submodules. Pretty much all.
Sep 26 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 26 September 2013 at 11:17:29 UTC, Dicebot wrote:

 ..


:%s/look/luck/g
Sep 26 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-26 13:17, Dicebot wrote:


 Good look getting all those small trivial libraries into official
 repositories. Actually, some distros even prohibit pure source packages
 at all.


That's exactly why dub _should_ install packages. If you don't like, 
don't use it.


 You should install it because you are tired of satisfying build
 dependencies manually and it is a bit more robust than git submodules.
 Pretty much all.


How is it more robust than git submodules? It does basically the same.

-- 
/Jacob Carlborg
Sep 26 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 26/09/2013 07:59, Jacob Carlborg wrote:

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


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


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


Are... you... serious?... O_O

There are incredibly important benefits for development-time usage.
To automatically fetch the required dependencies, making sure they are 
correct for you application. Easily upgrade the version of dependencies? 
Support multiple build configurations (including for example unittest 
runners)? Supporting all the previous functionality in a way that is 
replicable across different machines? Have other tools such as IDEs 
understand the source and build structure of your 
application/project/library??

System package managers don't support this because they are not 
cross-platform. Even if cross-platform wasn't an issue, there might 
still be several shortcomings or inadequacies with OS package managers 
because they are more often geared torwards end-user installation, not 
development-time usage.

-- 
Bruno Medeiros - Software Engineer
Sep 26 2013
next sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 26/09/2013 15:16, Bruno Medeiros wrote:

 To automatically fetch the required dependencies, making sure they are
 correct for you application.


When I say "correct" here, I also mean "compatible", in case that's not 
clear.

-- 
Bruno Medeiros - Software Engineer
Sep 26 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 26.09.2013 16:24, schrieb Bruno Medeiros:

 On 26/09/2013 15:16, Bruno Medeiros wrote:

 To automatically fetch the required dependencies, making sure they are
 correct for you application.


 When I say "correct" here, I also mean "compatible", in case that's not
 clear.


Even C++ has them on Windows nowadays via NuGet,

http://docs.nuget.org/docs/reference/support-for-native-projects
Sep 26 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-26 16:16, Bruno Medeiros wrote:


 Are... you... serious?... O_O

 There are incredibly important benefits for development-time usage.
 To automatically fetch the required dependencies, making sure they are
 correct for you application. Easily upgrade the version of dependencies?
 Support multiple build configurations (including for example unittest
 runners)?




 Supporting all the previous functionality in a way that is
 replicable across different machines?


It's not, that's another big issue with dub. It doesn't lock the 
dependency graph. If you have the packages:

My own package:

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

Third party package:

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

Another third party package:

{
     "name": "xyz"
}

Say I install package "foo" on a machine. It will install package 
"bar-0.0.1" and "xyz-0.0.1" just as it should. Then an hour later I 
install the same package, "foo", on a different machine. Then suddenly 
it install "xyz-0.0.2". Surprise surprise, it's not the same application 
anymore and you have no idea if the application is working or not.

Of course, it's unlikely this will happen within an hour. But try six 
months later and you might end up with a completely different application.


 Have other tools such as IDEs  understand the source and build structure of
your
 application/project/library??

 System package managers don't support this because they are not
 cross-platform. Even if cross-platform wasn't an issue, there might
 still be several shortcomings or inadequacies with OS package managers
 because they are more often geared torwards end-user installation, not
 development-time usage.


I'm not saying that all other features are not useful but I'm saying 
that it doesn't actually install the packages is a big issue.

-- 
/Jacob Carlborg
Sep 26 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, September 26, 2013 22:05:35 Jacob Carlborg wrote:

 It's not, that's another big issue with dub. It doesn't lock the
 dependency graph. If you have the packages:


This is definitely something that needs to be sorted out.

- Jonathan M Davis
Sep 26 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-27 02:20, Jonathan M Davis wrote:

 This is definitely something that needs to be sorted out.


I talked with Sönke about this in the dub forum. He thinks the current 
behavior should be default and could possibly add a new flag, 
--lock-dependencies, which locks the dependency graph. I think it should 
be the other way around. The dependency graph should be locked by default.

-- 
/Jacob Carlborg
Sep 26 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 26/09/2013 21:05, Jacob Carlborg wrote:

 Are... you... serious?... O_O

 There are incredibly important benefits for development-time usage.
 To automatically fetch the required dependencies, making sure they are
 correct for you application. Easily upgrade the version of dependencies?
 Support multiple build configurations (including for example unittest
 runners)?




 Supporting all the previous functionality in a way that is
 replicable across different machines?


 It's not, that's another big issue with dub. It doesn't lock the
 dependency graph. If you have the packages:

 My own package:

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

 Third party package:

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

 Another third party package:

 {
      "name": "xyz"
 }

 Say I install package "foo" on a machine. It will install package
 "bar-0.0.1" and "xyz-0.0.1" just as it should. Then an hour later I
 install the same package, "foo", on a different machine. Then suddenly
 it install "xyz-0.0.2". Surprise surprise, it's not the same application
 anymore and you have no idea if the application is working or not.

 Of course, it's unlikely this will happen within an hour. But try six
 months later and you might end up with a completely different application.


 From what I understand, for dependency graph locking to work at all, 
then each package (as stored in the central package repository) would 
have to specify its full dependency graph in the package specification. 
So the foo package would have to specify not only the bar dependency, 
but also xyz=0.0.1 as a dependency. Isn't that how it would work?
If so, I think that might be too constricting, and might introducing 
other kinds of problems and limitations. (what if you know xyz=0.0.2 is 
safe to use, and want to install foo with that?)

Rather, I think dub should adopt Semantic Versioning as part of its 
recommended practices for package versioning:
http://semver.org/spec/v2.0.0.html
In this practice, stuff like "xyz": ">=0.0.1" is not recommended, an 
upper bound on the version is required, to allow breaking changes in xyz.


-- 
Bruno Medeiros - Software Engineer
Oct 08 2013
next sibling parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 08/10/2013 11:51, Bruno Medeiros wrote:

 Rather, I think dub should adopt Semantic Versioning as part of its
 recommended practices for package versioning:
 http://semver.org/spec/v2.0.0.html
 In this practice, stuff like "xyz": ">=0.0.1" is not recommended, an
 upper bound on the version is required, to allow breaking changes in xyz.


Doh, I should have checked this before I posted, but dub does this already:
http://code.dlang.org/package-format#version-specs

That means all packages (at least production ready ones) should use 
upper bounds on their dependencies.

-- 
Bruno Medeiros - Software Engineer
Oct 08 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-08 12:51, Bruno Medeiros wrote:


  From what I understand, for dependency graph locking to work at all,
 then each package (as stored in the central package repository) would
 have to specify its full dependency graph in the package specification.
 So the foo package would have to specify not only the bar dependency,
 but also xyz=0.0.1 as a dependency. Isn't that how it would work?


No, now necessarily. Using Bundler it works like this:

* You have your Gemfile, corresponds to package.json in dub
* You run "bundle install"

* When you do that it will create a new file, Gemfile.lock. This file 
contains the complete dependency graph of what it just installed.

* Running "bundle install" when Gemfile.lock exist, it will read 
Gemfile.lock instead of Gemfile

By the way, the registry (package repository) need to be able to figure 
you the complete dependency graph, otherwise it won't be very effective. 
It should only require one single HTTP request to the registry to get 
the complete list of dependencies of a given package.


 If so, I think that might be too constricting, and might introducing
 other kinds of problems and limitations. (what if you know xyz=0.0.2 is
 safe to use, and want to install foo with that?)


The way I've done that using Bundler is to explicitly specify that as a 
direct dependency, in this case of "foo". I don't know if there's a 
better way.


 Rather, I think dub should adopt Semantic Versioning as part of its
 recommended practices for package versioning:
 http://semver.org/spec/v2.0.0.html
 In this practice, stuff like "xyz": ">=0.0.1" is not recommended, an
 upper bound on the version is required, to allow breaking changes in xyz.


Semantic versioning helps, but it won't solve the problem. I wouldn't 
trust that a library actually follows the semantic versioning scheme. 
It's quite easy to accidentally add new API without incrementing the 
middle number. Or break the API.

-- 
/Jacob Carlborg
Oct 08 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 08/10/2013 13:38, Jacob Carlborg wrote:

 On 2013-10-08 12:51, Bruno Medeiros wrote:


  From what I understand, for dependency graph locking to work at all,
 then each package (as stored in the central package repository) would
 have to specify its full dependency graph in the package specification.
 So the foo package would have to specify not only the bar dependency,
 but also xyz=0.0.1 as a dependency. Isn't that how it would work?


 No, now necessarily. Using Bundler it works like this:

 * You have your Gemfile, corresponds to package.json in dub
 * You run "bundle install"

 * When you do that it will create a new file, Gemfile.lock. This file
 contains the complete dependency graph of what it just installed.

 * Running "bundle install" when Gemfile.lock exist, it will read
 Gemfile.lock instead of Gemfile


Rigth, but then you would need to share the .lock file to the other 
machine you want to install/compile "foo" in. The repository alone would 
not be enough for that.


 Rather, I think dub should adopt Semantic Versioning as part of its
 recommended practices for package versioning:
 http://semver.org/spec/v2.0.0.html
 In this practice, stuff like "xyz": ">=0.0.1" is not recommended, an
 upper bound on the version is required, to allow breaking changes in xyz.


 Semantic versioning helps, but it won't solve the problem. I wouldn't
 trust that a library actually follows the semantic versioning scheme.
 It's quite easy to accidentally add new API without incrementing the
 middle number. Or break the API.


Hum that is true. Especially without a tool that can verify API 
compatibility.


-- 
Bruno Medeiros - Software Engineer
Oct 10 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-10-10 14:25, Bruno Medeiros wrote:


 Rigth, but then you would need to share the .lock file to the other
 machine you want to install/compile "foo" in. The repository alone would
 not be enough for that.


Yes, absolutely. In the Rails world it's recommended that you add both 
Gemfile and Gemfile.lock to the SCM for you're Rails applications. For 
Rails plugins you should only add Gemfile to SCM.

You usually don't have your Rails application uploaded to RubyGems.

-- 
/Jacob Carlborg
Oct 10 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-25 18:14, Bruno Medeiros wrote:


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


We can take Eclipse as an other example. It has a built in package 
manager for plugins. Would you prefer that it just downloaded Java 
source files. Then you have to manually build the plugin and figure out 
where to place it to have Eclipse recognize it?

-- 
/Jacob Carlborg
Sep 26 2013
parent Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 26/09/2013 21:11, Jacob Carlborg wrote:

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


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


 We can take Eclipse as an other example. It has a built in package
 manager for plugins. Would you prefer that it just downloaded Java
 source files. Then you have to manually build the plugin and figure out
 where to place it to have Eclipse recognize it?


No, I wouldn't prefer that.

I'm not saying it's not useful to have an end-user package manager. It 
is. But I think that the development use-cases and functionality are 
more important, and therefore dub should focus primarily (if not 
exclusively) on those.

-- 
Bruno Medeiros - Software Engineer
Sep 27 2013
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 11 September 2013 06:48, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular S=C3=B6nke has been very active abou=


t

 maintaining and improving it, which brings further confidence in the futu=


re

 of the project.

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



Is there a front-end for dub floating around?
Something like the cygwin package installer comes to mind... (nothing fancy=
)

I've used dub once, I was very satisfied with the experience. I think a
front-end where you can browse the repository and select/deselect packages
conveniently would be a great addition to the experience, if it's not
already available.
Sep 26 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-26 09:44, Manu wrote:


 Is there a front-end for dub floating around?
 Something like the cygwin package installer comes to mind... (nothing fancy)

 I've used dub once, I was very satisfied with the experience. I think a
 front-end where you can browse the repository and select/deselect
 packages conveniently would be a great addition to the experience, if
 it's not already available.


I'm wondering how that would look like. Because apparently people don't 
like dub to actually install packages. If dub doesn't install packages I 
don't think it would gain much of over browsing the registry:

http://code.dlang.org/

-- 
/Jacob Carlborg
Sep 26 2013
parent reply Manu <turkeyman gmail.com> writes:
On 26 September 2013 18:24, Jacob Carlborg <doob me.com> wrote:


 On 2013-09-26 09:44, Manu wrote:

  Is there a front-end for dub floating around?

 Something like the cygwin package installer comes to mind... (nothing
 fancy)

 I've used dub once, I was very satisfied with the experience. I think a
 front-end where you can browse the repository and select/deselect
 packages conveniently would be a great addition to the experience, if
 it's not already available.


 I'm wondering how that would look like. Because apparently people don't
 like dub to actually install packages. If dub doesn't install packages I
 don't think it would gain much of over browsing the registry:

 http://code.dlang.org/



Is that not a package list?

I only just skimmed this thread, but it seemed dub installs packages to
me...
What did it install when I told it to install vibe.d and some other
companion pieces then?
Sep 26 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-26 10:39, Manu wrote:


     http://code.dlang.org/


 Is that not a package list?

 I only just skimmed this thread, but it seemed dub installs packages to
 me...
 What did it install when I told it to install vibe.d and some other
 companion pieces then?


If you run "dub install" it will only clone the repository and its 
dependencies. It will not compile anything and it won't put the 
resulting binaries (which don't exist) in a easily accessible location.

Although it can be useful to integrate in an IDE, but that will only be 
useful for libraries. Not for executables, since they're not installed.

-- 
/Jacob Carlborg
Sep 26 2013
prev sibling parent "develop32" <develop32 gmail.com> writes:
On Thursday, 26 September 2013 at 07:44:25 UTC, Manu wrote:

 I've used dub once, I was very satisfied with the experience. I 
 think a
 front-end where you can browse the repository and 
 select/deselect packages
 conveniently would be a great addition to the experience, if 
 it's not
 already available.


Do you mean a tool that edits package.json file?
I see little gain in having GUI for that.
Sep 26 2013
prev sibling next sibling parent reply "Chad Joan" <chadjoan gmail.com> writes:
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei 
Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while 
 and things are going well. In particular Sönke has been very 
 active about maintaining and improving it, which brings further 
 confidence in the future of the project.

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


 Andrei


I hate to be /that guy/, but...

Sönke, have you considered using TOML as an editable 
serialization/configuration format?
https://github.com/mojombo/toml

It's easy on the eyes, has a simple grammar, and seems to have at 
least /some/ buy-in from other communities.

I'm just not sure if it has all of the features you desire; you 
would know better than I.
Sep 26 2013
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org> writes:
Am 26.09.2013 15:35, schrieb Chad Joan:

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

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


 Andrei


 
 I hate to be /that guy/, but...
 
 Sönke, have you considered using TOML as an editable
 serialization/configuration format?
 https://github.com/mojombo/toml
 
 It's easy on the eyes, has a simple grammar, and seems to have at least
 /some/ buy-in from other communities.
 
 I'm just not sure if it has all of the features you desire; you would
 know better than I.


I think as a configuration format that makes a lot of sense. However, it
looks like it may get tricky/impossible to define lists of complex
entities, such as for the "configurations" section.

Also SDL has the not to be underestimated advantage of allowing the
repeated use of the same tag to define lists, which cuts down the
nesting level by one for each such list, or allows to define constructs
that have a more imperative feel to them (rather than purely declarative).

Maybe the example [1] could also be adjusted for TOML to get a better
feeling for it, though.

[1]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/
Sep 26 2013
parent reply "user" <user test.com> writes:
How about this:


=== JSON
=================================================================
{
	"name": "my-package",
	"description": "A package for demonstration purposes",
	"dependencies": {
		"vibe-d": ">=0.7.13",
		"sub-package": {"version": "~master", "path": "./sub-package"}
	},
	"configurations": [
		{
			"name": "console",
			"targetType": "executable",
			"versions": ["ConsoleApp"]
		},
		{
			"name": "gui",
			"targetType": "executable",
			"versions": ["ConsoleApp"],
			"libs-windows": ["gdi32", "user32"]
		}
	]
}

=== SLD
==================================================================
name "my-package"
description "A package for demonstration purposes"

dependency "vibe-d" version=">=0.7.13"
dependency "sub-package" version="~master" path="./sub-package"


configuration "console" {
	targetType "executable"
	versions "ConsoleApp"
	libs-windows "gdi32" "user32"
}


configuration "gui" {
	targetType "executable"
	versions "UseWinMain"
	libs-windows "gdi32" "user32"
}

=== TOML
=================================================================
name         = "my-package"
description  = "A package for demonstration purposes"

[[dependency.vibe-d]]
version = ">=0.7.13"

[[dependency.sub-package]]
version = "~master"
path    = "./sub-package"


[[configuration]]
name       = "console"
targetType = "executable"
versions   = "ConsoleApp"


[[configuration]]
name         = "gui"
targetType   = "executable",
versions     = ["ConsoleApp"],
libs-windows = ["gdi32", "user32"]

==========================================================================
Sep 27 2013
parent reply "user" <user test.com> writes:
Sorry, error in last post fixed. In TOML, "dependency" only needs 
single bracket, since it is a nested table.


=== JSON =======================================================
{
	"name": "my-package",
	"description": "A package for demonstration purposes",
	"dependencies": {
		"vibe-d": ">=0.7.13",
		"sub-package": {"version": "~master", "path": "./sub-package"}
	},
	"configurations": [
		{
			"name": "console",
			"targetType": "executable",
			"versions": ["ConsoleApp"]
		},
		{
			"name": "gui",
			"targetType": "executable",
			"versions": ["ConsoleApp"],
			"libs-windows": ["gdi32", "user32"]
		}
	]
}

=== SLD ========================================================
name "my-package"
description "A package for demonstration purposes"

dependency "vibe-d" version=">=0.7.13"
dependency "sub-package" version="~master" path="./sub-package"


configuration "console" {
	targetType "executable"
	versions "ConsoleApp"
	libs-windows "gdi32" "user32"
}


configuration "gui" {
	targetType "executable"
	versions "UseWinMain"
	libs-windows "gdi32" "user32"
}

=== TOML =======================================================
name         = "my-package"
description  = "A package for demonstration purposes"

[dependency.vibe-d]
version = ">=0.7.13"

[dependency.sub-package]
version = "~master"
path    = "./sub-package"


[[configuration]]
name       = "console"
targetType = "executable"
versions   = "ConsoleApp"


[[configuration]]
name         = "gui"
targetType   = "executable",
versions     = ["ConsoleApp"],
libs-windows = ["gdi32", "user32"]

================================================================
Sep 27 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 27 September 2013 at 09:12:34 UTC, user wrote:

 Sorry, error in last post fixed. In TOML, "dependency" only 
 needs single bracket, since it is a nested table.
 ...


I think SDL looks best of those 3.
Sep 27 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-09-27 13:24, Dicebot wrote:


 I think SDL looks best of those 3.


I agree, it almost looks like Ruby :). Although I don't really like that 
it's not a very common format, at least not as common as JSON.

-- 
/Jacob Carlborg
Sep 27 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-10 22:48, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


The name "package.json" is already used by NPM (node package manager). 
Should we rename the package file or should we just ignore the conflict?

-- 
/Jacob Carlborg
Sep 27 2013
parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 27.09.2013 14:04, schrieb Jacob Carlborg:

 On 2013-09-10 22:48, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


 The name "package.json" is already used by NPM (node package manager).
 Should we rename the package file or should we just ignore the conflict?


Although the conflict will probably not matter in practice, I think just 
"dub.json" would be better. The name "package.json" is still from the 
early days when it was called VPM.
Sep 27 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 27/09/2013 18:12, Sönke Ludwig wrote:

 Am 27.09.2013 14:04, schrieb Jacob Carlborg:

 On 2013-09-10 22:48, Andrei Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while and
 things are going well. In particular Sönke has been very active about
 maintaining and improving it, which brings further confidence in the
 future of the project.

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


 The name "package.json" is already used by NPM (node package manager).
 Should we rename the package file or should we just ignore the conflict?


 Although the conflict will probably not matter in practice, I think just
 "dub.json" would be better. The name "package.json" is still from the
 early days when it was called VPM.


Any chance that Dub packages could be called something else instead, 
such as "bundles", throughout the documentation, wiki, etc.? The point 
here would be to limit cognitive confusion/overlap with D language 
packages. It's just a minor cleanup I know, and of subjective value, but 
still I think it would be nicer...

-- 
Bruno Medeiros - Software Engineer
Oct 08 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-10-08 12:55, Bruno Medeiros wrote:


 Any chance that Dub packages could be called something else instead,
 such as "bundles", throughout the documentation, wiki, etc.? The point
 here would be to limit cognitive confusion/overlap with D language
 packages. It's just a minor cleanup I know, and of subjective value, but
 still I think it would be nicer...


What if it always said "dub package"? There's always the chance of 
confusion. On Mac OS X a "bundle" is a special folder containing an 
executable or dynamic library plus its resources.

-- 
/Jacob Carlborg
Oct 08 2013
prev sibling parent "Joakim" <joakim airpost.net> writes:
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei 
Alexandrescu wrote:

 We've been experimenting with http://code.dlang.org for a while 
 and things are going well. In particular Sönke has been very 
 active about maintaining and improving it, which brings further 
 confidence in the future of the project.

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


 Andrei


Well, you've started the mother of all bikeshed threads, as every 
dev/sysadmin has a different opinion on how to handle packages. 
;) There have been some valid concerns raised about whether dub 
should do all the stuff it does, but I think they're largely moot 
at this point, given the small size of the D community.  Better a 
tool that does everything initially, as current D users are 
inevitably developers, which can then be split up and specialized 
later if necessary.


I've used dub on FreeBSD and was impressed with both the tool and 
how clean the code is, even though there were small 
linking/library incompatibilities that meant I had to hack a 
workaround into dub to compile vibe.d.  Sonke was remarkably 
responsive to my feedback, I cannot imagine there will be a 
better option for a D package manager and developer.
Sep 27 2013