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

Feature: Ability to run pizza routines #13

Open
bdougie opened this issue Jul 28, 2023 · 3 comments
Open

Feature: Ability to run pizza routines #13

bdougie opened this issue Jul 28, 2023 · 3 comments

Comments

@bdougie
Copy link
Member

bdougie commented Jul 28, 2023

What is a routing?

A routine is a combination of commands run in a subsequent combination.

This is related to #12 which will add the ability to bake multiple repos.

With multiple pizzas in the oven I would love to run insight and other commands are the bake repos.

I was watching a tutorial on openbb and learned about the idea of running routines for loaded or stashed stocks.

recording routines

I do encourage you to watch the video and see the recording feature at 7:33

$ pizza record

A recording captures the commands stores them a stashed state for easier recalling later on other baked repos. Imagine you run the same commands every morning and want to alias them into recording.

load/unload

The openbb provided the ability to load and unload stocks. This is similar to my other issue #11 on stashing.

single repo routines

A routine should also be able to run insights on a single repo.

@jpmcb
Copy link
Member

jpmcb commented Jul 28, 2023

Very interesting! I think this is a great idea.

Thinking out-loud, my main push-back would be, given a unix style command line utility, if someone was going to run the same commands every morning, the typical recommendation would be to write a script which uses good IO practices and builds on core functionality to make something more instead of build an extremely complex state and execution management system. Utilities like kubectl and helm have rejected these types of proposals in the past for this exact reason.

I.e., if I wanted to bake multiple repos and get the insights for them, I'd probably just write a script like:

#!/usr/bin/env bash

pizza  bake -f my-repos-to-bake.yaml
pizza insights ...
pizza insights ...
pizza insights ...

# etc

Meta-programming wise, this brings up some difficult problems: what happens if I execute record within record? What if I attempt to record or execute a routine from within a script not managed by a user? What happens if I attempt to execute a routine from within a record? The levels of inception get pretty deep relatively quickly.

But, I suppose, a record feature could be a really unique and interesting way to automatically build and store these types of scripts for users.

If we want to pursue this, we'll want to be very diligent to still enable good practices with having good i/o and single use commands in the unix philosophy.

@k1nho
Copy link
Contributor

k1nho commented Jul 28, 2023

A recording captures the commands stores them a stashed state for easier recalling later on other baked repos. Imagine you run the same commands every morning and want to alias them into recording.

I like to use fig usually for this, it allows to create scripts and have them on a single command, but also supports subcommands and other neat features. Thought, I understand having it on the CLI is just easier.

But, I suppose, a record feature could be a really unique and interesting way to automatically build and store these types of scripts for users.

Maybe, it can store the commands given in a file first, and give it an alias which can then be fetched via that alias pizza routine bakeAndInsight and invalidate nested record and routine calls on read. This makes it less flexible, but It would technically be like running the commands sequentially 🤔.

@bdougie
Copy link
Member Author

bdougie commented Jul 29, 2023

If we want to pursue this, we'll want to be very diligent to still enable good practices with having good i/o and single use commands in the unix philosophy.

I think a good practice would be ideal and recording the script for the user is the best approach.

Per @k1nho's mention I think the fig script approach may be something we can leverage/emulate. I also think invalidating nested recordings would be ideal for a first iteration since we wouldn't get in a place where we need to handle too many weird edge cases.

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

No branches or pull requests

3 participants