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

chore: update sprocket to latest WDL crate #46

Draft
wants to merge 11 commits into
base: main
Choose a base branch
from
Draft

Conversation

a-frantz
Copy link
Member

@a-frantz a-frantz commented Dec 17, 2024

This also adds the ability to check/lint URLs

closes #39
sort of closes #45 by providing --local-only and --single-document args which narrow the scope of printed diagnostics. It was decided over slack not to pursue either of the 2 fixes presented in #45 as they were likely undesirable UXs.

Before submitting this PR, please make sure:

  • You have added a few sentences describing the PR here.
  • You have added yourself or the appropriate individual as the assignee.
  • You have added at least one relevant code reviewer to the PR.
  • Your code builds clean without any errors or warnings.
  • You have added tests (when appropriate).
  • You have updated the README or other documentation to account for these changes (when appropriate).

This also adds the ability to check/lint URLs
@a-frantz a-frantz requested a review from peterhuene December 17, 2024 22:51
@a-frantz a-frantz self-assigned this Dec 17, 2024
@a-frantz a-frantz marked this pull request as ready for review December 18, 2024 15:28
CHANGELOG.md Outdated Show resolved Hide resolved
@a-frantz a-frantz marked this pull request as draft December 18, 2024 16:31
@a-frantz
Copy link
Member Author

This PR was put back into draft state and will remain as a draft until the wdl crates make an official release. In the meantime, I'll use this branch as the basis for the development of the other sprocket PRs I have planned.

This PR will have to be reviewed+merged before those other ones.

@@ -7,6 +7,17 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0

## Unreleased

### Changed

* Updated WDL crate to latest. This adds support for
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't Clay want to keep sprocket pinned to a release?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but that release doesn't exist yet. This PR will be updated to pull an official release once one exists.

I think the language here is fine? Maybe it should specify the version of "latest" once that is out?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I would swap latest with the version when it is known.

if !args.lint && !args.common.except.is_empty() {
bail!("cannot specify `--except` without `--lint`");
if args.common.shellcheck && !args.lint {
bail!("`--shellcheck` requires `--lint` to be enabled");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the experience we want or should --shellcheck add --lint automatically (with a warning)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could go either way I suppose. I don't think I feel strongly on this either way. Could it confuse users if they specify --shellcheck without --lint and then they see non-shellcheck lint diagnostics?

Comment on lines -185 to +270
"aborting due to previous {error_count} error{s}",
"failing due to {error_count} error{s}",
s = if error_count == 1 { "" } else { "s" }
);
} else if args.common.deny_warnings && warning_count > 0 {
bail!(
"aborting due to previous {warning_count} warning{s} (`--deny-warnings` was specified)",
"failing due to {warning_count} warning{s} (`--deny-warnings` was specified)",
s = if warning_count == 1 { "" } else { "s" }
);
} else if args.common.deny_notes && note_count > 0 {
bail!(
"aborting due to previous {note_count} note{s} (`--deny-notes` was specified)",
"failing due to {note_count} note{s} (`--deny-notes` was specified)",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this language change. I'm not sure the new proposed language makes it clear that sprocket is stopping because it has encountered too many errors/notes/warning.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this language is an improvement, but maybe it can be improved further. I don't like the aborting language because in my mind it implies that sprocket was going to do something else but it's quitting early. This really just controls whether it's a non-zero exit code or not.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you clarify the behavior here? sprocket is computing the full set of diagnostics, reporting all of them, and then setting the exit code if any of the requested subtypes has content?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are correct. The bail! macro exits the program with a non-zero exit code (IDK what code specifically) and this block of checks is the last thing sprocket is doing in check/lint mode. So there is no further computation that might occur if there aren't problems detected. This is the end no matter what.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I initially thought this was related to limiting the number of diagnostics emitted to the first N. I know that was discussed, but can't recall what the decision was.

Now that I understand it, I agree that the language is an improvement.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We did discuss that over slack, but it was decided that limiting to the first N would likely lead to a bad UX. So we always report the full set of diagnostics, with --local-only and --single-document controlling the scope of what's reported (but everything is always computed regardless)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the refresher, the after-effects of the holiday break are quite apparent today.

#[arg(required = true)]
pub paths: Vec<PathBuf>,
#[clap(value_name = "PATH or URL")]
pub file: String,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A potential nit @adthrasher : is file the right name for this arg? I couldn't think of a better name...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered commenting on that, but couldn't come up with an alternative I preferred. You could verbosely call it path_or_url.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eh. I think I prefer just plain path to path_or_url, but don't love either. I'll leave this comment unresolved in case someone else reviewing has a better alternative.

@@ -182,17 +257,17 @@ pub async fn check(args: CheckArgs) -> anyhow::Result<()> {

if error_count > 0 {
bail!(
"aborting due to previous {error_count} error{s}",
"failing due to {error_count} error{s}",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"failing due to {error_count} error{s}",
"failing with {error_count} error{s}",

How do you feel about with instead? I'm not certain that's an improvement.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. Kinda feels like half-dozen of one, 6 of the other to me. I don't see how it clarifies anything, but it doesn't seem worse in any way. I can make that change if you want. I'm fine with it.

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