-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some way to run multiple tasks at once #15
Comments
what about arguments to a cli? |
I think this would be limited to ones that do not require arguments. With the YAML one you could do it but I imagine that’d come later. |
Just randomly thinking about this... What about an interface that looks like.. LuckyTask::Runner.alias("db.redo") do |task|
task << "db.drop"
task << "db.create"
task << "db.migrate"
task << "db.insert --from=./whatever.json"
end Half baked idea, but we have a separate registry for aliases. Then when you run a task and it searches, it looks for registered tasks, then falls back to aliases before failing. If it finds an alias that matches, it could just run through each task you've appended with the full arg list. No clue how this would work, or if it would even work, but just something I thought of and wanted to write it down. |
I wonder who should be allowed to declare aliases? If I add a shard to my project, should I expect that it's able to declare aliases? (How would you stop it?) I'd change it so that aliases are implemented at the top of the preference stack rather than the bottom. It's probably bad practice, but if I write the code to redefine what 'db.migrate' does, then it should do what I tell it to rather than something else. If that's a toxic implementation, that can be filtered out at compile time with something like "err: attempted to define a task which is already defined". There's some fiddly bits about resolving the alias, because if you alias 'db.migrate' to ['db.reset', 'db.migrate'] you don't want to circularly de-reference your alias. |
I didn't consider this at the shard level 🤔 That's a good point though. I don't think it would be a good idea to override an existing task. Like if you wanted to redefine what I guess the other thing would be shipping off some custom task that does some weird things like |
lucky db.create,db.migrate,db.create_required_seeds
And/or with a lucky_cli.yaml file for defining aliases?
The text was updated successfully, but these errors were encountered: