Skip to content
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

Open
paulcsmith opened this issue Apr 28, 2020 · 5 comments
Open

Some way to run multiple tasks at once #15

paulcsmith opened this issue Apr 28, 2020 · 5 comments

Comments

@paulcsmith
Copy link
Member

paulcsmith commented Apr 28, 2020

lucky db.create,db.migrate,db.create_required_seeds

And/or with a lucky_cli.yaml file for defining aliases?

aliases:
  db.setup:
    - db.create
    - db.migrate
    - db.create_required_seeds
@jkthorne
Copy link

what about arguments to a cli?

@paulcsmith
Copy link
Member Author

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.

@jwoertink jwoertink transferred this issue from luckyframework/lucky_cli May 14, 2023
@jwoertink
Copy link
Member

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.

@robacarp
Copy link

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.

@jwoertink
Copy link
Member

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 db.migrate does, you'd have to call it something else like db.sqlize or something 😂 I believe we would have a way to know if the name is already taken.

I guess the other thing would be shipping off some custom task that does some weird things like db.drop; sudo rm rf / or whatever... Like, each task would have to be passed to LuckyTask, and not just running arbitrary CLI commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants