Shards installs wrong version of lucky

[robacarp]

With this shard file, I expect it to install lucky 1.0.0-rc1. That tag appears correct, and the version number in the shard.yml for the project is correct as well.

However, what it installs is v0.30.1 instead. Nothing I do can make it install correctly. With the shard file shared around, others are able to see the behavior as well.

This does not happen with shards 0.17.0 and crystal 1.5.1, but it happens reliably with crystal 1.6.0 and shards 0.17.1.

name: app
version: 0.1.0

crystal: 1.6.0

dependencies:
  lucky:
    github: luckyframework/lucky
    version: ~> 1.0.0-rc1 # branch: master

To clarify, the output of the shard command indicates that it understands the assignment and thinks it's doing the right thing, but what lands is incorrect:

$ shards install -v
Resolving dependencies
git ls-remote --get-url origin
Fetching https://github.com/luckyframework/lucky.git
git fetch --all --quiet
git ls-tree -r --full-tree --name-only refs/tags/v1.0.0-rc1 -- shard.yml
git show refs/tags/v1.0.0-rc1:shard.yml
...

$ cat lib/lucky/shard.yml | grep version | head -n 1
version: 0.30.1

Shards 0.17.1 (2022-09-30) MacOS

[robacarp]

Okay, so starting from the reduced shard.yml file above might not reproduce the error. However, when I use this full shard file it reproduces consistently.

Note that the crystal version specified as 1.4.1 does not match my shell, but it doesn't seem to affect anything by removing or changing it.

name: app
version: 0.1.0

crystal: 1.4.1

dependencies:
  icmp:
    github: robacarp/icmp.cr

  mosquito:
    github: mosquito-cr/mosquito
    version: ~> 1.0.0.rc1
      # path: ../../mosquito-cr/mosquito

  pundit:
    github: stephendolan/pundit

  breeze:
    github: luckyframework/breeze
    version: ~> 0.2

  lucky:
    github: luckyframework/lucky
    version: ~> 1.0.0-rc1 # branch: master

  avram:
    github: luckyframework/avram
    version: ~> 1.0.0-rc1 # branch: master

  faker:
    github: askn/faker

  lexbor:
    github: kostya/lexbor

  authentic:
    github: luckyframework/authentic
    version: ~> 0.9

  carbon:
    github: luckyframework/carbon
    version: ~> 0.3.0

  carbon_sendgrid_adapter:
    github: luckyframework/carbon_sendgrid_adapter
    version: ~> 0.3.0

  lucky_env:
    github: luckyframework/lucky_env

  jwt:
    github: crystal-community/jwt
    version: ~> 1.5.1

  honeybadger:
    github: honeybadger-io/honeybadger-crystal

development_dependencies:
  lucky_flow:
    github: luckyframework/lucky_flow
    version: ~> 0.7.3

[straight-shoota]

Try running with --skip-postinstall --skip-executables. It works as intended.

When running with postinstalls, I notice that lib/lucky and a couple other folders are changed after shards created them. So it seems like one of the postinstalls checks out a different version of the library (note that all lib/*/lib folders are symlinks to lib).

By the way

The postinstalls are taking a very long time for stuff I don't actually want and one (lexbor) even breaks because it's missing `cmake` (shameless plug for https://forum.crystal-lang.org/t/shards-postinstall-considered-harmful/3910).

[robacarp]

Thanks @straight-shoota, I appreciate this. I can confirm it is working as expected with these.

I notice that lib/lucky and a couple other folders are changed after shards created them.

Would you be willing to share what you did to notice that?

[straight-shoota]

Haha, very low-tech. Just an ls -l lib when each postinstall script runs. 🤷

[robacarp]

Here I was hoping you had some fancy shell magic. Thanks @straight-shoota, the problem is linked above at breeze.

[straight-shoota]

No, I didn't even bother to look something up.

But next I hacked into shards to remove write permissions for every library folder after it has been installed. Seems like avaram's postinstall also want's to write to a shard.lock file 👿