xc icon indicating copy to clipboard operation
xc copied to clipboard

idea: non-executable (display only) tasks

Open a-h opened this issue 10 months ago • 2 comments

I have found myself regularly doing this sort of thing:

### list-schemas

To list schemas, connect to Trino and run the following command:

```
echo "SHOW TABLES FROM hive.s3_input;"
```

Because some tasks are not fully automated, and require a manual step of some sort. However, having them in the list is useful.

It would be handy if xc had a "manual" step which just printed out the command instead.

For example:

Executable: false

a-h avatar Mar 10 '25 15:03 a-h

Interesting! I can see the benefits, I'll have to think about the way that it is configured. I'm always hesitant now to add new "task attributes" because it's hard to make their usage super obvious with a concise name.

A couple of alternative ideas:

Add a new enum to the Run attribute:

Run: always - default, means a task can be ran multiple times as a requirement of other tasks.
Run: once - means a task is only ran once per `xc` invocation.
Run: print - prints the text.

Allow echo as a code block type (maybe isn't that intuitive)

```echo
SHOW TABLES FROM hive.s3_input;
```

Add a new flag (means you have to provide the flag every time)

# just prints the script rather than running
xc -d list-schemas

joerdav avatar Mar 11 '25 09:03 joerdav

@a-h are you interested in discussing more why the step isn't practical to be executed? Maybe we can find a way to actually enable execution of the task, rather than providing this as a fallback.

In your example, you talk about connecting to a server to run SQL. In org-mode (without xc) we can do something like this:

** Database tasks
:PROPERTIES:
:header-args:sql: :engine postgres
:header-args:sql+: :dbhost my.database-host.com :dbport 5432
:header-args:sql+: :dbuser postgres :dbpassword my-password
:END:

*** list-schemas

#+begin_src sql
  SHOW TABLES FROM hive.s3_input;
#+end_src

When you run that SQL code block, it takes the header args from the properties section and uses it to construct a database connection to a remote server, and the code is piped through that connection.

If xc's command runner could run code on another machine, would that allow you to actually run tasks in the way that you want, eliminating the need for display-only tasks?

ryanprior avatar Oct 31 '25 01:10 ryanprior