Adding a version manager.

[usern3]

I just switched from a 0.26 project to a 0.25 to help someone. Ended up changing my mind because I'd have to do 2 Lucky installs. And there's no CLI commands are usable. It doesn't even recognize it's a Lucky program

Any chance we can add lucky-cli to ASDF or give its own version manager.

Working on projects with multiple lLucky versions will become a nightmare. Especially as Lucky grows and people are usng different versions. It becomes a dev nightmare.

If we could inregrate into ASDF it would be even more better (yes thats improper english).

Hell, even backwards compatibility would be good enough in some cases.

[usern3]

Example of how ASDF handles crystal versioning

after running asdf local crystal 0.35.1

[usern3]

Any idea's for doing this. with Lucky-cli?

[stephendolan]

I actually responded in Discord! I think the best approach would be an ASDF plugin: https://discord.com/channels/743896265057632256/743896265057632259/820779943029768212

You could put together a proof of concept on your personal GitHub, then we could upstream it if it works well for you!

[matthewmcgarvey]

Another option worth looking into is including a lucky binary in projects like rails does with bin/rails so that you don't have to use the global cli

[robacarp]

Yep. If that's too heavy I get it, but that would make it smooth and easy to write tutorials as well.

[matthewmcgarvey]

Alrighty, so compiling tasks.cr is not a great idea because if you make changes to the app they won't be picked up. For example: the routes task pulls the routes from the router (link) and routes added after it's compiled would not be picked up.

The easiest way to add a script/lucky file would be to just have the file do:

#!/usr/bin/env bash

crystal tasks.cr "$@"

Real complicated right?

[robacarp]

Hm, interesting. I guess this issue started off being about a development workflow but I'd been thinking about it in terms of a deployment workflow.

I don't often use the routes command, and it's never used in a deployment. In my projects I have this in my shard.yml:

targets:
  server:
    main: src/start_server.cr
  worker:
    main: src/app_worker.cr
  tasks:
    main: tasks.cr

Then, from docker I call shards build, and at the entrypoint I can run bin/server or bin/worker, but most importantly I run bin/tasks db.migrate. The benefit here is that I can run a multi-stage build and only copy over the binaries I need for the given container.

---

In a development environment the goal is to have a shortcut to running the generators based off of the lucky version the app is targeting, and I guess I'd want to be able to cache the output of that so it doesn't take so long to compile. Trade-offs.

I think what you have will make sense and lower the burden of maintenance.

[robacarp]

Currently bin/lucky is a directory containing exec, gen, and watch, which I assume a system lucky delegates to, so making bin/lucky executable might be more rework than I initially thought

[robacarp]

I also just ran into this: migrations are cataloged and checked when the app is compiled, so attempting to run migrations with an out of date lucky binary will cause an incorrect "no migrations" message to appear.

[peterhoeg]

This may a little further away from what you were asking for, but you could consider https://github.com/NixOS/nix - we only carry the latest version of lucky-cli but it's trivial to override things on a project specific basis and use custom versions.

[jwoertink]

Nix has the LuckyCli on it? 🤔 That's pretty neat!

[peterhoeg]

Nix has the LuckyCli on it? 🤔 That's pretty neat!

We might be getting slightly off-topic here, but neat indeed! Decent support for crystal in general as well. That being said there is still quite a bit that can be done on https://github.com/nix-community/crystal2nix so do come by. I have the skeleton for a blog post about working with lucky/crystal on nix.