-
Notifications
You must be signed in to change notification settings - Fork 394
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
ref: rewrap a couple usage blocks #3345
Conversation
d131954
to
0491087
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to handle this criteria in the auto-formatter/linter?
Meaning the line length specific to code blocks? I don't think so unfortunately, in fact md code blocks are allowed any line width by the linter, I think. We should always sanity check the rendered review app before merging -- that's how I detect code blocks with scroll bars. |
usage: dvc repro [-h] [-q | -v] [-f] [-s] [-m] [--dry] [-i] | ||
[-p] [-P] [-R] [--no-run-cache] [--force-downstream] | ||
[--no-commit] [--downstream] [--pull] [--glob] | ||
usage: dvc repro [-h] [-q | -v] [-f] [-s] [-m] [-i] [-p] [-P] [-R] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this groups all the short flags at the start? Looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But then there's additional reordering within some of the long flags. Can you give some rationale for the order @jorgeorpinel?
I'm not sure if there was any rationale for the current order. cc @iterative/dvc If you have any context for the order of arguments under these commands, please add your thoughts 🙏 .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think that on the core repo, currently new arguments are just added at the bottom so there's no logical order.
My criteria here isn't super defined but broadly: put general ones in the first line, esp. if they're shot flags; Then group by functionality in the order in which we think people will use them most -- in the case above (repro
) realted to deps/params, then outs/metrics/plots, then DVCLive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we move [--no-exec] [--no-run-cache] [--no-commit]
to the bottom for run
and stage add
, can we put the related repro
options [--pull] [--no-run-cache] [--no-commit]
at the end here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Should the ordering criteria be translated back to dvc core repo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, once there is an agreement on the order of everything, we should update the core repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
move [--no-exec] [--no-run-cache] [--no-commit] to the bottom for run
Done. Well, I moved them above the DVCLive ones. PTAL
and stage add
Doesn't have them.
put the related repro options [--pull] [--no-run-cache] [--no-commit] at the end
Done.
- BTW
run --no-exec
is equivalent torepro --dry
right? May want to rename the former to "dry" as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- BTW
run --no-exec
is equivalent torepro --dry
right? May want to rename the former to "dry" as well.
I think --dry
is reserved for commands that are read-only and make no actual changes to the repo state, whereas run --no-exec
is basically dvc stage add
and still writes the stage to dvc.yaml
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
repro
is not read-only; It changes the repo state. So should its --dry
be renamed --no-exec
then? UPDATE: Moved to iterative/dvc#7522
[-m <path>] [-M <path>] | ||
[--plots <path>] [--plots-no-cache <path>] | ||
[--live <path>] [--live-no-cache <path>] | ||
[--live-no-html] [-w <path>] | ||
[--always-changed] [--external] [--desc <text>] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And these are stage-level options?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Least used options
I approved this again but is this an epic? |
No but there are follow up tasks (I'll make an issue after this or something). |
Co-authored-by: Dave Berenbaum <[email protected]>
…to dvclive/refs-rewrap
* ref: rewrap a couple usage blocks per #3325 (review) and #3325 (review) * ref: reorg repro/run/stage add usage block * move run/repro exec modifyer options down per #3345 (comment) * Update content/docs/command-reference/repro.md Co-authored-by: Dave Berenbaum <[email protected]> * ref: make run options like stage add per #3345 (review) Co-authored-by: Dave Berenbaum <[email protected]>
Some quality-related ideas on what criteria to use when formatting usage blocks. Potentially we can later match this in the core repo too (
-h
help output).run/repro/stage add
: regroup options/flags dvc#7524