Making compile the default subcommand in prqlc

[snth]

Hi,

As mentioned during the dev call, I believe that the majority of people most of the time just want to translate PRQL code to SQL and therefore the prqlc CLI should be geared towards making that as simple as possible.

I currently use the following shell function for this personally:

prql() { ([ -z "$1" ] || [ -f "$1" ]) && prqlc compile "$@" || echo "$1" | prqlc compile - "${@:2}"; }

So I can do things like:

❯ prql "from hello | select world"
SELECT
  world
FROM
  hello

-- Generated by PRQL compiler version:0.9.4 (https://prql-lang.org)

or

❯ prql 'from albums.csv | take 1' | duckdb
┌──────────┬───────────────────────────────────────┬───────────┐
│ album_id │                 title                 │ artist_id │
│  int64   │                varchar                │   int64   │
├──────────┼───────────────────────────────────────┼───────────┤
│        1 │ For Those About To Rock We Salute You │         1 │
└──────────┴───────────────────────────────────────┴───────────┘

My little one-liner still supports parameters so I can also do things like:

❯ prql 'from `schema.albums` | take 1' -t sql.bigquery --no-format
SELECT * FROM `schema.albums` LIMIT 1 -- Generated by PRQL compiler version:0.9.4 target:sql.bigquery (https://prql-lang.org)

The interactive no-parameter and file based modes are also still supported:

❯ prql test.prql
SELECT
  *
FROM
  t

-- Generated by PRQL compiler version:0.9.4 (https://prql-lang.org)

❯ prql 'from `schema.albums`' out.sql && cat out.sql
SELECT
  *
FROM
  "schema.albums"

-- Generated by PRQL compiler version:0.9.4 (https://prql-lang.org)

❯ prql
Enter PRQL, then press ctrl-d to compile:

from [{bye="now"}]
WITH table_0 AS (
  SELECT
    'now' AS bye
)
SELECT
  bye
FROM
  table_0

-- Generated by PRQL compiler version:0.9.4 (https://prql-lang.org)

I've stopped short of checking for the other subcommands and then supporting those because that would break my one-liner rule and I think that would be better supported in prqlc itself.

[snth]

Based on this reply to this StackOverflow question I think you would just need to wrap the Command enum with Option here and then modify the match code below.

The match code might become a bit more cumbersome since you probably need to match on all the options now but it should be doable. I also thought this might be a good #first-issue since it only touches the CLI code. It's something I'm quite confident I could do if I had the time which is why I think the #good-first-issue label might be appropriate.

[snth]

Similarly I think the input in IoArgs here should check wether the string it received is - or a valid path to a file that exists and if not then assume that it represents the PRQL query to be translated similarly to how I do it with my shell function examples above.

I think that would add a lot in convenience in day to day usage.

[max-sixty]

I'm somewhat torn — on the one hand, having obvious things be obvious is the design we should be aiming for — and prqlc compile is very likely to be the only thing most folks do (particularly if they're not developing the library, which is an underweight voice in discussing what we should do). duckdb is a great example here.

But on the other, are we going to make it quite complicated? Does prqlc parse look for a file named parse?

Other options:

• a shortcut, like prqlc c
• have the other things be options, like --output-stage=RQ.
  • I had already started on something to allow arbitrary input & output stages, because, for example, it's not currently possible to go from PL to RQ.
  • This doesn't allow for much hierarchy though
  • We replace prqlc fmt with prqlc --output-stage=prql though, which seems worse...

[eitsupi]

As I mentioned in Discord, I think it is an interesting case that yq allows subcommands yq eval yq e to be abbreviated to yq.
https://mikefarah.gitbook.io/yq/commands/evaluate

[max-sixty]

I agree re shortcuts, though my guess is that it won't satisfy the "hardcore simplifiers" :)

One thing we could do, if the code didn't get too complicated, is use prqlc compile when piping stdin to prqlc

• there's no ambiguity between a command and an argument
• it shortens the command for the use case which is "fastest". Then if someone is compiling a project, then need to run prqlc compile $path

[snth]

But on the other, are we going to make it quite complicated? Does prqlc parse look for a file named parse?

No, I don't think so. I think from a user perspective nothing changes other than that they can optionally leave out "compile". At least that's my impression from the StackOverflow How to make a default subcommand with clap and derive I refenced. It makes the clap cli code slightly more complicated but my understanding is that because of Rust's strict type system and pattern matching it would actually identify what you want. There may be some ambiguous corner cases where it fails but I think in general it should work. I guess we'd have experiment and try it out first for a bit.

[snth]

The alternative is just to introduce another prql binary produced by the crate for the everyday user which just has the simple functionality of my bash script above. We can then leave prqlc unchanged for the compiler hackers and enthusiasts. I think prql is a slightly nicer name for a CLI command anyway.

[max-sixty]

There may be some ambiguous corner cases where it fails but I think in general it should work. I guess we'd have experiment and try it out first for a bit.

I agree in general it'll work! I'm still a bit worried about the corner cases. For example:

Does prqlc parse look for a file named parse?

Or — presumably prqlc pars [sic], will give an error like "Can't find file named pars", which is fairly confusing?

---

WDYT about limiting this to just piping PRQL into stdin?