You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since we're asking the user to copy-paste one or two commands anyway, I think it would be easier to understand if we try to replace meltano_tut references with their native invocations.
meltano_tut init
echo "=== Running wrapped 'meltano init' ==="
rm meltano.yml
meltano init new_project
rm new_project/README.md
mv new_project/* .
rm new_project
mkdir data
cp codespaces_tutorial/customers.csv data/customers.csv
echo "=== Now head to the README.md and continue with step 2!"
I think we can safely assume a new project - and the 'reset' functions can be moved to something like a dedicated tutorial_reset.sh.
We don't need to move the csv, do we? We could start with it already in data or tutorial_data and just access it from there during the EL step.
Then, the replacement could just be meltano init ..
Just to reaffirm why 4. is necessary: because the VS Code extension otherwise won't work (right now) :-) (And I do want to change the default environment to codespaces, so we do kind of need a meltano.yml in place)
So I do think that's fine, although I also was thinking about a "tutorial" command. Some CLIs have that and it's kind of nice. I think and enables an even better workflow control.
Since we're asking the user to copy-paste one or two commands anyway, I think it would be easier to understand if we try to replace
meltano_tut
references with their native invocations.meltano_tut init
tutorial_reset.sh
.data
ortutorial_data
and just access it from there during the EL step.meltano init .
.meltano init
in a non-empty directory meltano#6954The text was updated successfully, but these errors were encountered: