Duplicate attribute error

[mamantoha]

Crystal 0.35.0 Shards 0.11.1

Running shards install on one of my projects.

Error:

in shard.yml: duplicate attribute: version at line 8, column 1

  6. 
  7. crystal: 0.22.0
  8. version: 0.3.2

I have a lot of shards defined in shard.yml and I don't understand which of them causes this error. Can we make the output of check_duplicate method more verbose?

Link to the repository: https://github.com/mamantoha/detransport_lviv_telegram/

[jacobh0]

We are receiving the same error, and I actually believe this is a parsing regression for shards. None of the individual shard files have duplicate attributes.

[jacobh0]

Little update after some investigation:

If you do not specify a version or branch, like so:

  jennifer:
    github: imdrasil/jennifer.cr

The parser appears to pick a seemingly random tag from the repo. We haven't really been able to figure out the exact behavior, but it's undesirable. Perhaps this should simply be disallowed? Adding a version/branch fixes the issue.

[Blacksmoke16]

Without a version it should use the latest tag that is satisfiable based on current Crystal version.

[jacobh0]

The root problem appears to be in the dependencies of the "latest version" of the shard that does not have a version specified. I don't believe it is working as intended, but have little more info to add. We have had to manually specify the latest version to work around the issue.

[netarc]

It should resolve to latest; but it clearly doesn't seem to be doing that when looking at verbose output (should resolve to 0.9.0):

➜ shards install -v
Resolving dependencies
git ls-remote --get-url origin
Fetching https://github.com/imdrasil/jennifer.cr.git
git fetch --all --quiet
git ls-tree -r --full-tree --name-only refs/tags/v0.9.0 -- shard.yml
git show refs/tags/v0.9.0:shard.yml
git ls-remote --get-url origin
Fetching https://github.com/phoffer/inflector.cr.git
git fetch --all --quiet
git ls-tree -r --full-tree --name-only refs/tags/v0.1.8 -- shard.yml
git show refs/tags/v0.1.8:shard.yml
git ls-remote --get-url origin
Fetching https://github.com/imdrasil/ifrit.git
git fetch --all --quiet
git ls-tree -r --full-tree --name-only refs/tags/v0.1.2 -- shard.yml
git show refs/tags/v0.1.2:shard.yml
git ls-remote --get-url origin
Fetching https://github.com/TechMagister/i18n.cr.git
git fetch --all --quiet
git ls-tree -r --full-tree --name-only refs/tags/v0.3.1 -- shard.yml
git show refs/tags/v0.3.1:shard.yml
git tag --list --column=never
git ls-tree -r --full-tree --name-only refs/tags/v0.2.0 -- shard.yml
git show refs/tags/v0.2.0:shard.yml
git ls-tree -r --full-tree --name-only refs/tags/v0.2.1 -- shard.yml
git show refs/tags/v0.2.1:shard.yml
git ls-tree -r --full-tree --name-only refs/tags/v0.2.3 -- shard.yml
git show refs/tags/v0.2.3:shard.yml
git ls-tree -r --full-tree --name-only refs/tags/v0.3.0 -- shard.yml
git show refs/tags/v0.3.0:shard.yml
git ls-tree -r --full-tree --name-only refs/tags/v0.3.1 -- shard.yml
git show refs/tags/v0.3.1:shard.yml
git ls-tree -r --full-tree --name-only refs/tags/v0.3.2 -- shard.yml
git show refs/tags/v0.3.2:shard.yml
in shard.yml: duplicate attribute: version at line 8, column 1
  6.
  7. crystal: 0.22.0
  8. version: 0.3.2
     ^

Perhaps it's getting confused when looking through dependencies..?

[Blacksmoke16]

The problem is when you don't specify a version/branch/commit, it'll fetch all the versions of the shard to determine which one best satisfies the requirements. In this case, when it gets to version 0.3.2, at the time of that version, there were duplicate keys, https://github.com/imdrasil/jennifer.cr/blob/v0.3.2/shard.yml.

IMO the solution here would be to specify a version/commit for each of your dependencies. This is not only a best practice, but would tell the resolver that it doesn't need to go back that far.

Checkout https://github.com/crystal-lang/shards/blob/master/SPEC.md#version-1 for the possible options related to the version property.

[jacobh0]

Thanks for the extra clarification here @Blacksmoke16, much appreciated! I agree, just best practice to be specific.