Handling tasks with edge cases

[jwoertink]

Related: #1566

Right now we precompile a selected set of tasks. The ones that are precompiled are the tasks that generally won't change between two separate apps. For example, lucky gen.task CustomTask. That task would run the exact same between 2 separate Lucky apps, so this means we can precompile it, and when you run it, it's fast. However, lucky db.migrate would run different between two Lucky apps because the database is different, credentials may be different...

With that said, if you look at the related issue, you'll see that in some cases, someone might want to change how the inflectors are setup. This would change the output between two different apps when doing a lucky gen.whatever. To fix this, you would need to know to delete the precompiled tasks you intend to run, and then recompile them.

What sort of options do we have to make this a better experience? Here's my ideas:

• Assume the edge case will always be around Wordsmith, and fix Wordsmith to take a config/inflectors.cr file in to consideration.
• Don't make any task precompiled...
• Same, but make a step after you've generated your Lucky app to compile all of them
• Same, but after you run your first task, it just compiles them all for you. (how would you know when to refresh this?)
• Leave as is, but add heavy documentation to cover these sort of cases

What are your thoughts on these options? Do you have any other ideas for options?

[btihen]

I personally favor the idea that the task compilation happens in a separate step & the setup script suggest you write config files & then do the task compilation (after configs that affect tasks). Ideally every time the task compilation is re-run (refreshed) - it reviews all configs again.

All but the last option would also benefit from a warning / notice (that sees when configs have changed and suggest a task recompile - if workable).

[robacarp]

I have two possible answers to the problem. First, more directly to the issue of compiling tasks. A useful paradigm for this kind of thing has been around for a long time in the make utility. The logic is straightforward for humans, and not too bad for computers. If files of a given path change, recompile X binary. One of my complaints about lucky (and crystal) is the development time lag. A lot of the time there's no need to recompile the tasks because there's no changes to the lucky tasks. In this case the internationalization stuff could be a pre-requisite for the gen tasks.

The second is, what if we moved the inflection into a runtime evaluated file, like toml or something?

[jwoertink]

I've thought about the same path of compile the file, and each time it's ran, just check if there's been change. If there has been changed, then recompile and run, otherwise just run it. I think the tricky part there is how to decide what files you're watching for? You can't really watch for all of them because it would mean almost always recompiling. I think the db.console task only needs to know about config/database.cr as where the db.migrate task needs to know about the config/database.cr and all of the migration files. In the case of this issue, any generator task would need to know about a config/inflectors.cr file for change.

I wonder if there's a way to generate some hash based on what crystal needs to build a binary? 🤔 Like, if I have a program that require "a" and require "b", we generate some sort of hash. Then if anything in the program, or a, or b change, it would generate a new hash...

OOooo... Also, with all this new crystal i stuff coming... We could just make tasks interpreted 😄 Then it won't matter!