search

alexherbo2 / kakoune.cr

A command-line tool for Kakoune
https://kakoune.org
The Unlicense
54 stars 11 forks source link

Check in shard.lock #5

Closed loewenheim closed 3 years ago

loewenheim commented 3 years ago

Per https://crystal-lang.org/reference/the_shards_command/index.html, the shard.lock file should be checked into version control for applications.

alexherbo2 commented 3 years ago

I don’t like to store lock files, but if it is a blocker for the packaging I will do.

What is the recommendation when the project is an application and a library?

It could be nice for example, to be usable with crun.

loewenheim commented 3 years ago

It's not a blocker for my nixpkgs package at least—it needs a lock file, but I can just add one from a successful build. To be honest I don't really know what to do for a library and application in one. It's probably fine to leave it without one.

loewenheim commented 3 years ago

Btw, thank you very much for this program. It's been a huge boost to my productivity and is much easier to use than connect was.

Parasrah commented 3 years ago

As someone who has been burned by not having a lockfile committed in version control in the past, I would strongly recommend you commit the lockfile. Of course it's completely your decision, just my recommendation. I have a project that is now dead because I left it for a few months and when I came back I could no longer build it. The new versions of dependencies that automatically got installed no longer worked together, and I couldn't for the life of me figure out specifically the right combination to get a successful build. A lockfile ensures your build is reproducible in the future