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

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

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)

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

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.

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"

# command line version
configuration "console" {
	targetType "executable"
	versions "ConsoleApp"
	libs-windows "gdi32" "user32"
}

# Win32 based GUI version
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"

# command line version
[[configuration]]
name       = "console"
targetType = "executable"
versions   = "ConsoleApp"

# Win32 based GUI version
[[configuration]]
name         = "gui"
targetType   = "executable",
versions     = ["ConsoleApp"],
libs-windows = ["gdi32", "user32"]

==========================================================================

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"

# command line version
configuration "console" {
	targetType "executable"
	versions "ConsoleApp"
	libs-windows "gdi32" "user32"
}

# Win32 based GUI version
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"

# command line version
[[configuration]]
name       = "console"
targetType = "executable"
versions   = "ConsoleApp"

# Win32 based GUI version
[[configuration]]
name         = "gui"
targetType   = "executable",
versions     = ["ConsoleApp"],
libs-windows = ["gdi32", "user32"]

================================================================

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

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

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.