RejectedSoftware Forums

Sign up

Cannot Specify Package Version

When building packages you are required to give a version for every dependency, but currently there is no way to specify a version for your package.

Re: Cannot Specify Package Version

On Tue, 04 Mar 2014 20:39:28 GMT, Jeroen Bollen wrote:

When building packages you are required to give a version for every dependency, but currently there is no way to specify a version for your package.

you define the version via github tags. but good question about the version of local packages...

Re: Cannot Specify Package Version

Created an issue for it: https://github.com/rejectedsoftware/dub/issues/267

Re: Cannot Specify Package Version

On 05/03/2014 10:38, Stephan Dilly wrote:

On Tue, 04 Mar 2014 20:39:28 GMT, Jeroen Bollen wrote:

When building packages you are required to give a version for every dependency, but currently there is no way to specify a version for your package.

you define the version via github tags. but good question about the version of local packages...

What do you mean?
You can use the version attribute in dub.json if it's not under a git
repo to define the version of your package.

Bruno Medeiros
https://twitter.com/brunodomedeiros

Re: Cannot Specify Package Version

On Wed, 05 Mar 2014 15:56:36 +0000, Bruno Medeiros wrote:

On 05/03/2014 10:38, Stephan Dilly wrote:

On Tue, 04 Mar 2014 20:39:28 GMT, Jeroen Bollen wrote:

When building packages you are required to give a version for every dependency, but currently there is no way to specify a version for your package.

you define the version via github tags. but good question about the version of local packages...

What do you mean?
You can use the version attribute in dub.json if it's not under a git
repo to define the version of your package.

Bruno Medeiros
https://twitter.com/brunodomedeiros

The version attribute isn't defined anywhere, and it doesn't seem to work either.

Re: Cannot Specify Package Version

Failed to retrieve metadata for package app:common: Could not find package candidate for app:common ==~>1.0
Could not resolve dependencies
The dependency graph could not be filled, there are unresolved dependencies.
The following changes will be performed:
Failure app:common ==~>1.0, userWide
Issued by:
app:engine: ==~>1.0
Checking dependencies in '/home/jeroen/Documents/Projects/App/engine/'
Failed to retrieve metadata for package app:common: Could not find package candidate for app:common ==~>1.0
Could not resolve dependencies
The dependency graph could not be filled, there are unresolved dependencies.
The following changes will be performed:
Failure app:common ==~>1.0, userWide
Issued by:
app:engine: ==~>1.0
Error executing command build: Unknown dependency: app:common

All packages exists, app:common has "version": "1.0.0".

Re: Cannot Specify Package Version

On 05/03/2014 18:49, Jeroen Bollen wrote:

On Wed, 05 Mar 2014 15:56:36 +0000, Bruno Medeiros wrote:

On 05/03/2014 10:38, Stephan Dilly wrote:

On Tue, 04 Mar 2014 20:39:28 GMT, Jeroen Bollen wrote:

When building packages you are required to give a version for every dependency, but currently there is no way to specify a version for your package.

you define the version via github tags. but good question about the version of local packages...

What do you mean?
You can use the version attribute in dub.json if it's not under a git
repo to define the version of your package.

Bruno Medeiros
https://twitter.com/brunodomedeiros

The version attribute isn't defined anywhere, and it doesn't seem to work either.

It's not documented, that's true. It should.

It seems to be working for me, but not for sub-packages. I put a
"version" : "1.0.0"
on a sub-package, but dependency resolution fails, and 'dub list' lists
the sub-package version the same as the parent: "~master"

For top-level packages it seems to be working fine.

Bruno Medeiros
https://twitter.com/brunodomedeiros

Re: Cannot Specify Package Version

On Thu, 06 Mar 2014 00:19:01 +0000, Bruno Medeiros wrote:

On 05/03/2014 18:49, Jeroen Bollen wrote:

On Wed, 05 Mar 2014 15:56:36 +0000, Bruno Medeiros wrote:

On 05/03/2014 10:38, Stephan Dilly wrote:

On Tue, 04 Mar 2014 20:39:28 GMT, Jeroen Bollen wrote:

When building packages you are required to give a version for every dependency, but currently there is no way to specify a version for your package.

you define the version via github tags. but good question about the version of local packages...

What do you mean?
You can use the version attribute in dub.json if it's not under a git
repo to define the version of your package.

Bruno Medeiros
https://twitter.com/brunodomedeiros

The version attribute isn't defined anywhere, and it doesn't seem to work either.

It's not documented, that's true. It should.

It seems to be working for me, but not for sub-packages. I put a
"version" : "1.0.0"
on a sub-package, but dependency resolution fails, and 'dub list' lists
the sub-package version the same as the parent: "~master"

For top-level packages it seems to be working fine.

Bruno Medeiros
https://twitter.com/brunodomedeiros

That seems to be indeed the case.

Re: Cannot Specify Package Version

One difference I'm having though, is all my packages, regardless of them being parent or sub, regardless of the version tag being in the dub.json, show up as being on the "~master" branch.

Re: Cannot Specify Package Version

Generally all sub packages must have the same version as the root
package (the git tag approach can't work otherwise), so if they need to
have different versions, they should be separate packages instead.

For local packages there are some bugs present w.r.t. version inference
(including erroneously treating everything as ~master). This has only
been discovered recently and will be resolved in 0.9.22.

Regarding the "version" field, it hasn't been documented, because all
implications of using it manually haven't been properly investigated,
yet. It shouldn't be used for public packages for now, but for local
ones that don't live in a git repository it's still a viable workaround.
Local packages that do live in a git repository are still better off
with a git tag, but this of course requires fixing the "~master" bug first.

BTW 0.9.22 is planned to be done quite soon, in about 2 weeks (or at
least a first pre-release).