cog icon indicating copy to clipboard operation
cog copied to clipboard

Integration with PEP723 scripts

Open LecrisUT opened this issue 6 months ago • 4 comments

It would be nice if this can support calling hatch run/pipx run/uv run as part of the logic. The benefit there is that that will handle pulling any relevant dependencies.

My thinking for the design is that if a path/file is provided, than run it with one of those tools. Configurable on the cli. My understanding is that there is no information passed to the scripts, but if needed, there could be a standardised input for that.

LecrisUT avatar May 10 '25 12:05 LecrisUT

I'm sorry, I don't understand what you are getting at. The Python code in the cog fragments can do whatever it wants to do, including running other programs in subprocesses. Can you give me a very concrete example of how uv run could fit into it?

nedbat avatar May 11 '25 19:05 nedbat

The idea is to simplify the user setup from

/*[[[cog
import subprocess

subprocess.run("hatch run my_script.py")
...
]]]*/
//[[end]]

to just

//[[[cog my_script.py]]]
//[[end]]

Some benefits would be:

  • cog can ensure that a run frontend is present and switch to an appropriate one if one is not hard-coded. E.g. on the CI pipx is pre-installed so that could be used, while on the developer side, they might have hatch or uv prepared instead.
  • cog could better handle what goes on the stdout/stderr and inside cog.out
  • simpler execution that does not require generation of a python script, handling module visibility and all of that. Just parsing stdin/stdout/stderr. Some better io handlers can be provided if more customization is needed

LecrisUT avatar May 12 '25 07:05 LecrisUT

I can see how that would be powerful. I'm reluctant to sniff out the package tooling in place and choose one to run the program though. How complex do you think it would get?

nedbat avatar May 12 '25 12:05 nedbat

How complex do you think it would get?

Complexity I don't think it would be complex, but it would require quite some changes to separate from cog's python module injection. We can start small and have just running the script and figure out what the IO would be like. Then adding the run frontend would be just switching from sys.executable to a supported frontend

LecrisUT avatar May 12 '25 13:05 LecrisUT

Instead of assuming uv, or even Python. Why not instead provide something generic like a more succinct way of invoking a shell command?

The user syntax could be something new:

/// [[[cog $uv run foo.py]]]

Or a function

/// [[[cog
/// cog.shell("uv run foo.py")
/// ]]]

(Or both)

thejcannon avatar Jul 04 '25 21:07 thejcannon

This doesn't seem like a burden to me, and doesn't require any changes to cog, or any new learning on the part of the author:

/*[[[cog
import subprocess

subprocess.run("hatch run my_script.py")
...
]]]*/
//[[end]]

nedbat avatar Aug 31 '25 12:08 nedbat