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

docs: Add more examples for toml tasks #3491

Merged
merged 10 commits into from
Dec 12, 2024
Merged

Conversation

hverlin
Copy link
Contributor

@hverlin hverlin commented Dec 12, 2024

No description provided.

@@ -143,10 +141,60 @@ run = 'echo {{flag(name=("myflag")}}'
# runs: echo true
```

```toml
[tasks.maybeClean]
run = """if [ '{{flag(name='clean')}}' = 'true' ]; then echo 'cleaning' ; fi""",
Copy link
Owner

Choose a reason for hiding this comment

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

seems like a missed opportunity to show how multiline strings work in toml. The comma at the end is also a syntax error


[tasks.download_task]
description = "Shows that you can use deno in a task"
shell = 'deno eval'
Copy link
Owner

Choose a reason for hiding this comment

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

while this works, it can also be done with a shebang:

run = """
#!/usr/bin/env -S deno run --allow-env
"""

which I prefer even though users need to understand env -S (which I don't see as a downside, env -S is great). I think we should show both methods.

Copy link
Owner

Choose a reason for hiding this comment

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

I don't know this for sure, but I suspect a shebang would also be easier for IDEs to syntax highlight, so I think that should be our preferred method here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was thinking that this solution is more portable, maybe? Need to try on windows to see what happens.

I am not sure if it makes a diff for syntax highlighting for languages that don't have # comments
image

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah wait, this is mise parsing the script actually, so it should work on window then.

let shell_type: Option<ShellType> = shell_from_shebang(script)
.or(task.shell())
.unwrap_or(SETTINGS.default_inline_shell()?)[0]

Copy link
Owner

Choose a reason for hiding this comment

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

I think that is only partially done, the shell_type there is only used for knowing whether or not it should escape args but I plan to soon make it actually parse and execute the shebang directly instead of going through sh -c. I would still document it this way, the windows issue I'll fix soon.

Copy link
Owner

Choose a reason for hiding this comment

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

if only I knew the mise-vscode maintainer ;)

Copy link
Owner

Choose a reason for hiding this comment

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

I do think syntax highlighting with shebangs would be a killer feature, or even if you got it to default to multiline strings as bash

Copy link
Owner

Choose a reason for hiding this comment

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

btw we should add your extension to the docs

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, I will make a PR next week. Want to check the windows support first

Copy link
Owner

Choose a reason for hiding this comment

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

might be worth waiting until I get the shebang parsing fully in place—right now it almost certainly will fail with any shebang—though a user could work around that with run_windows

Comment on lines 177 to 179
shell = 'deno eval' # or use a shebang: #!/usr/bin/env -S deno run
run = """
import ProgressBar from "jsr:@deno-library/progress";
Copy link
Owner

Choose a reason for hiding this comment

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

sorry, this is what I meant

Suggested change
shell = 'deno eval' # or use a shebang: #!/usr/bin/env -S deno run
run = """
import ProgressBar from "jsr:@deno-library/progress";
run = """
#!/usr/bin/env -S deno run
import ProgressBar from "jsr:@deno-library/progress";

@jdx
Copy link
Owner

jdx commented Dec 12, 2024

this is just a note, but there actually is a scenario where you may prefer shell = to the shebang, the shebang only works on a single run command, e.g.:

[tasks.foo]
run = [
"""
#!/usr/bin/env node
console.log("node")
""",
"""
#!/usr/bin/env bash
echo "foo"
""""

but of course shell would work on all of them. Why would someone want multiple run commands with different shells? no idea, but it's permitted.

I don't think it's worth documenting this

@hverlin
Copy link
Contributor Author

hverlin commented Dec 12, 2024

image

Added a code group with various examples


[tasks.python_task]
run = """
#!/usr/bin/env -S python
Copy link
Owner

Choose a reason for hiding this comment

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

we should reserve env -S for shebangs that have multiple args (like deno run). We should also document on this page what the heck env -S does in a callout of some kind. I suspect most users won't have a clue what it means. I think I already do that in the tips and tricks doc but this page is going to be far more heavily trafficked.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good, I will update 👍

@jdx
Copy link
Owner

jdx commented Dec 12, 2024

sorry for a bit of back and forth on this, but I think I know what I want to do in regards to documenting shell vs shebang. I think it's great to have multiple languages but I think for a few reasons shebangs should be the golden path. One is that it's more flexible, another is we should (at some point) get syntax highlighting for it, so I think we shouldn't document shell at all in the sort of introduction part of this.

What we do need on this page though is an exhaustive list of all the properties you can pass to tasks like we have for settings. That's where shell should go. That could be done here (even if it's just shell right now) or in a follow-up at some point.

@jdx
Copy link
Owner

jdx commented Dec 12, 2024

the tricky thing about that list though is almost all properties are associated with file and toml tasks. So I'm not sure where it should live.

@hverlin
Copy link
Contributor Author

hverlin commented Dec 12, 2024

I would document them in the toml task documentation. In the file task, given that there are a few examples already, we can just add a link indicating that the same properties are supported (https://mise.jdx.dev/tasks/file-tasks.html#arguments)

@jdx
Copy link
Owner

jdx commented Dec 12, 2024

one more thing, I've been using """, but I think we actually want to use '''

@jdx
Copy link
Owner

jdx commented Dec 12, 2024

oh whoops, seems I am not using sh -c when there is a shebang:

if script.starts_with("#!") {

I forgot about that. idk what this means for windows but it may work? probably not though

@jdx jdx merged commit 8551448 into jdx:main Dec 12, 2024
19 checks passed
@hverlin
Copy link
Contributor Author

hverlin commented Dec 12, 2024

Still had one commit to make 😅


## quiet

Set `quiet = false` to supress mise additional output.
Copy link
Contributor

Choose a reason for hiding this comment

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

@hverlin should this be quiet = true?

Copy link
Owner

@jdx jdx Dec 13, 2024

Choose a reason for hiding this comment

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

wait I think I missed this, we don't actually have this lol, this was a feature idea

Copy link
Owner

Choose a reason for hiding this comment

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

maybe I'll just implement it so we don't need to remove it

Copy link
Owner

Choose a reason for hiding this comment

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

fixed in #3514

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, this is why I was asking in the discord

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Other fixes: #3501

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

Successfully merging this pull request may close these issues.

3 participants