RejectedSoftware Forums

Sign up

Conflicting package multi-references while going bleeding edge

Hi,
I was toying around when I tried to add mysql-native in the dependencies.
I am using vibe.d master. It seems to me that ~master is not recognized as >= *.

How to reproduce:

xxxx@xxxx:~$ ll ~/.dub/packages/
total 32
drwxr-xr-x 6 xxxx xxxx 4096 Nov 24 07:27 ddox-0.9.15
drwxr-xr-x 4 xxxx xxxx 4096 Nov 14 00:32 libevent-master
drwxr-xr-x 4 xxxx xxxx 4096 Nov 14 00:33 libev-master
drwxr-xr-x 3 xxxx xxxx 4096 Nov 24 12:38 mysql-native-master
drwxr-xr-x 4 xxxx xxxx 4096 Nov 14 00:33 openssl-master
drwxr-xr-x 7 xxxx xxxx 4096 Nov 14 00:33 vibe-d-0.7.17
drwxr-xr-x 7 xxxx xxxx 4096 Nov 18 15:32 vibe-d-0.7.18-beta.2
drwxr-xr-x 6 xxxx xxxx 4096 Nov 24 07:08 vibe-d-master
xxxx@xxxx:~$ dub init test-conflict vibe.d
Successfully created an empty project in '/home/xxxx/test-conflict'.
xxxx@xxxx:~$ cd test-conflict/

Edit package.json set dependencies as:
"vibe-d": "~master",
"mysql-native": "~master"

xxxx@xxxx:~/test-conflict$ dub
Checking dependencies in '/home/xxxx/test-conflict'
The same package is referenced in different paths:
  vibe-d ~master: /home/xxxx/.dub/packages/vibe-d-master
  vibe-d 0.7.18-beta.2: /home/xxxx/.dub/packages/vibe-d-0.7.18-beta.2
Error: Conflicting package multi-references.

Run 'dub help' for usage information.
xxxx@xxxx:~/test-conflict$ 

More infos:

xxxx@xxxx:~/test-conflict$ uname -a && dub help | tail -n1
Linux xxxx 3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13) x86_64 GNU/Linux
DUB version v0.9.20-beta.3-6-g5857c6c
xxxx@xxxx:~/test-conflict$ cat ~/.dub/packages/mysql-native-master/package.json | grep "dependencies" -A5
	"dependencies": {
		"vibe-d": {
			"version": ">=0.7.17",
			"optional": true
		}
	},

Re: Conflicting package multi-references while going bleeding edge

On Sun, 24 Nov 2013 11:56:43 GMT, Mathias LANG wrote:

Hi,
I was toying around when I tried to add mysql-native in the dependencies.
I am using vibe.d master. It seems to me that ~master is not recognized as >= *.

How to reproduce:

xxxx@xxxx:~$ ll ~/.dub/packages/
total 32
drwxr-xr-x 6 xxxx xxxx 4096 Nov 24 07:27 ddox-0.9.15
drwxr-xr-x 4 xxxx xxxx 4096 Nov 14 00:32 libevent-master
drwxr-xr-x 4 xxxx xxxx 4096 Nov 14 00:33 libev-master
drwxr-xr-x 3 xxxx xxxx 4096 Nov 24 12:38 mysql-native-master
drwxr-xr-x 4 xxxx xxxx 4096 Nov 14 00:33 openssl-master
drwxr-xr-x 7 xxxx xxxx 4096 Nov 14 00:33 vibe-d-0.7.17
drwxr-xr-x 7 xxxx xxxx 4096 Nov 18 15:32 vibe-d-0.7.18-beta.2
drwxr-xr-x 6 xxxx xxxx 4096 Nov 24 07:08 vibe-d-master
xxxx@xxxx:~$ dub init test-conflict vibe.d
Successfully created an empty project in '/home/xxxx/test-conflict'.
xxxx@xxxx:~$ cd test-conflict/

Edit package.json set dependencies as:
"vibe-d": "~master",
"mysql-native": "~master"

(...)

Currently, you need to set the dependencies to {"vibe-d": ">=0.7.17", "mysql-native": "~master"}, as "~master" and a versioned release are considered conflicting when required by different packages. This is meant to be changed, but the best semantics are not yet clear (e.g. should ">=0.7.17" && "~master" result in "~master" or in "0.7.17", maybe depending on the hierarchical order?).

Re: Conflicting package multi-references while going bleeding edge

On Sun, 24 Nov 2013 13:12:48 GMT, Sönke Ludwig wrote:

Currently, you need to set the dependencies to {"vibe-d": ">=0.7.17", "mysql-native": "~master"}, as "~master" and a versioned release are considered conflicting when required by different packages. This is meant to be changed, but the best semantics are not yet clear (e.g. should ">=0.7.17" && "~master" result in "~master" or in "0.7.17", maybe depending on the hierarchical order?).

I edited package.json in ~/.dub/packages/mysql-native-master so it's working on the dependencies part for me.

So, tell me if I'm wrong, but I see that ATM working with 2 projects depending on each other is not possible if one of them use ~master and not the other.
Of course I understand why project can't depend on each other's master, but as I see it it makes testing a lot harder.

So I would say this should be package-level only, and dependencies should keep the same behaviour. If a conflict appear, the project's package.json should resolve it.

Then if:

  • Project (P) depends on A and B, and B depends on A, the version of A defined in P gets picked, and a warning may be issued;
  • P depends on A and B, which both depends on C on version / ~master, then same error message;
    --> P should depends on A and B and C, and A and B's dependencies gets overloaded (+ warning?);

Then you can say "I know what I'm doing", but you still get a warning.
Would that be a possible solution ?