pkgxdev
inside venv, `tea --help` lists available targets
@miles170 if I might employ a little psi::ESP, I believe this means:
"If tea --help is run in a directory with a README.md file, parse the README and look for possible build targets, as usable by useExecutableMarkdown. If found, add this information to a new section in the --help output, indicating that those are runnable targets for the environment (possibly including text context, if present, from the README)."
At least, that's where I'd start my attack. ;)
yep @jhheider has it.
You can useVirtualEnv to see if there is a virtual-env, and if so after tea’s help list the available targets. We define targets as:
# TargetName
Description of this target’s purpose.
\`\`\`sh
the commands the target runs
\`\`\`
useExecutableMarkdown.ts is where the code should go
How should I consider a markdown header a valid target?
If I use teaxyz/cli README.md as a sample, it will treat treattea/cli 0.13.0 as a target, but the code block is not a valid sh code.
fair point. Originally when devising this system I figured we should have a magic comment of some kind to indicate that a given code block is exe/md, and this indeed confirms that.
Now to field ideas…
Would it be a good idea to use code block language?
# TargetName
Description of this target’s purpose.
\`\`\`tea
the commands the target runs
\`\`\`
The downside is lost syntactic highlighting.
Good thinking, but I did intend for the \``language` specification to dictate what package is used as interpreter, which is probably still a better idea.
Other options include requiring a comment (it could be an HTML comment so it doesn’t show up in the rendered markdown).
I don’t particularly like that either.
it will treat treattea/cli 0.13.0 as a target
tea considers this the VERSION specifier and leading title, we could just ignore leading titles. This isn’t enough though since there are many code-blocks. We certainly need more rules of “sensible human default” kind here.
How about extending the language specification to something like {tea language='sh'} or <tea language="sh"/>?
## TargetName
Description of this target’s purpose.
\`\`\`{tea language=sh}
echo "Hello World"
\`\`\`
Alternatively, a magic comment can be used.
## TargetName
<!-- MAGIC KEYWORD HERE? -->
Description of this target’s purpose.
\`\`\`sh
echo "Hello World"
\`\`\`
Keeping the block spec will enable tools to keep syntax highlighting. Maybe a regex that matches ^\``.*\n(#|//)\s*tea$`?
Keeping the block spec will enable tools to keep syntax highlighting. Maybe a regex that matches
^\```.*\n(#|//)\s*tea$?
Something like?
## TargetName
Description of this target’s purpose.
\`\`\`sh
# MAGIC KEYWORD HERE?
echo "Hello World"
\`\`\`
I can think of two easy options (or maybe they're the same option):
^(#|//)\s+tea, or possibly ^(#|//)\s+tea.$extension to indicate the script's language (tea.ts, tea.rb, tea.py, etc).
There is one big problem: we simply use ^#+\\s+(.*)\\s*$ to match markdown headers, which will cause comments inside code blocks to be misidentified as headers.
\`\`\`sh
# THIS SHOULD NOT BE TAKEN AS A HEADER
\`\`\`
Shouldn't we first convert markdown to AST?
might have to. it's the standard "process C multiline comments" issue. I think we've package flex and bison? Maybe? So, it might be possible to use one of those. Not cheap though.
might have to. it's the standard "process C multiline comments" issue. I think we've package flex and bison? Maybe? So, it might be possible to use one of those. Not cheap though.
I couldn't find the Flex Bison package in the code repository.
By the way, what formatter do you guys use? I can't find a good way to format code.
github.com/westes/flex gnu.org/bison
I disabled my code formatter since it was fighting with whatever Max was doing (VSCode default, maybe? Anything other than that should be in .vscode/settings.json.
github.com/westes/flex gnu.org/bison
I disabled my code formatter since it was fighting with whatever Max was doing (VSCode default, maybe? Anything other than that should be in
.vscode/settings.json.
Both are 404 not found. May I request that @mxcl share the formatter configuration?
Oops. I linked to the prior, private version of the pantry. Fixing.
github.com/westes/flex gnu.org/bison
Oops. I linked to the prior, private version of the pantry. Fixing.
Before I get started, I'd like to confirm: should I use repl to run Flex or Bison inside the temporary sandbox and then return the results to deno?
Well, I don't even know that flex/bison is the right parser for what you want to do, but they are venerable. In general, if you needed a tool within the CLI that is provided by tea, you'd call install for the package, then use run() or backticks() to execute it. See Unarchiver.ts for a tool that requires its own packages.
Obviously, if you need a different tool to construct a Markdown AST, you'll probably want to PR it to pantry.extra.
Shouldn't we first convert markdown to AST?
For sure we should. The regex tokenization is a quick and dirty effort that should be replaced with a real markdown parser. Since deno can use npm modules now we may want to import one.
Shouldn't we first convert markdown to AST?
For sure we should. The regex tokenization is a quick and dirty effort that should be replaced with a real markdown parser. Since deno can use npm modules now we may want to import one.
Please check PR https://github.com/teaxyz/cli/pull/212. I have imported https://esm.sh/[email protected] to convert markdown into AST.
I think one solution is to require projects to explicitly declare a dependency on tea.xyz/exe/md in their dependencies. I'm noodling how this might work and then we can make exe/md a tea/cmd and then tea itself becomes leaner, where exe/md is just a package choice like any other.