tags: `PRQL`
----

# 2023-10-15

# 2023-10-01

# 2023-09-03

- Tobias: given that we'll have a few PRQL talks in the near future, we should look at PRQL onboarding process:
- re-package cli for Python and R, so people don't need to compile it with cargo
- prqlc: make `compile` the default command, so we can `echo 'from a' | prqlc`
- prqlc: add a flag to pass the query in directly: `prqlc compile -q 'from a'`

- regarding presenations:
- Max: arrays and modules should be deemphaized,
becuase that's what we are currently focused on,
and not what's important to people adopting the language
- Aljaz: we can invite people to contribute and checkout extentions that already exits
- Tobias: we should be prepared for question: "How do you compare to X query builder"
- query builders are limited to the language that they are written in,
- PRQL has lazy evaluation (instead of eager as pandas),
- PRQL can be much less verbose, compared to column names in string literals,
- LSP support, auto complete

- Tobias: we could improve Python bindings to the compiler by adding a query builder
- Aljaz: we should improve UX of importing .prql files into Python code,
because that way, we can provide syntax highlighting and auto complete

- Rich on marketing:
- don't say "unfortunately": don't promote things that we almost have,
focus on what we already have, is well designed and compiles already

- Tobias on language design:
- case should use `[]` instead of `{}`,
becuase element of the case block must have the same type
- we want an easy way to convert between "a bunch of .prql files" and "a single source file",
- `std.in` should support arrays (mostly literals, but subqueries too)

- Rich:
- most of queries that we use to highlight PRQL features on the website
don't really make sense when you think about the data that it is operating on.
- I'll work on new examples that still hightlight the features, but also make sense
- When this is done, we can have a button next to examples that opens it in the playground

- Tobias: could we have typo corrector saying "this column XX does not exist, you probably mean XY"

- Max: I wish things like this feature could be easily added into the compiler

# 2023-08-20

- Aljaz will work on QCon presentation,
- Tobias will work on ApacheCon presentation,
- module docs need updating

# 2023-08-06

# 2023-07-16

# 2023-07-02

- 0.9 needs work on `count s"*"` followup language change,
- Tobias wants to write-up a piece for the 0.9,
- we should split docs into "tutorials" and "reference",
- we are applying for PyCon ZA,
- there is a DuckDB bot for Discord, we could do a prql bot?
- ideas for project boosting:
- posting PRQL snippets, maybe from the playground (as Rust), which is a bit too much work, maybe just a Discord channel for people to post their gists,
- we could register an emoji domain, connected to PRQL. Would have a bit of a wow factor.

# 2023-06-18

# 2023-06-04

- Max
- Aljaz
- Tobias

Notes:
- what's left for 0.9?
- new int division: on website generated SQL of generic dialect is too complex. Let's make generic dialect "a dialect that looks nice, but is not guaranteed to work with any database".
- new s-string-based SQL backend, is the binding strength mechanism too spread around different files?
- we can change all binary operations to use s-strings? We have to check how would this effect performance
- relation literals: Does ideomatic PRQL conatin `from` at the begining of pipelines that start with a relation literal? We decided: yes
- prqlc fmt: indentation of 2 spaces instead of 4? Maybe.
- the ordering PR: when a sorting is constructed from an ordering, any uncomparable elements are placed at the end.
- for the next meeting: the PRQL MVP. Lutra, TUI, something else?

# 2023-05-07

- Max
- Aljaz

Talking about future of the project, where to focus. Lutra.

# 2023-03-19

## Who's here & update

- Max — done a few rusty PR, usual Issue & PR management, a few tweets from the PRQL account
- Aljaz — slow two weeks, bindings support, changing prql-lib, PHP & Dotnet. Decided to go back to actual compiler code. Started RFCs on types & modules.
- Tobias

## To discuss

- Should we annotate the types in something like flat buffers, to avoid having to create types in each language?
- Probably not worth spending time on now, but maybe in the future — we're not really using the RQ & PL types anyway
- Discussion on https://github.com/PRQL/prql/issues/2168 and https://github.com/PRQL/prql/issues/1535 — Max to think more and write up
- #1998 — @aljazerzen is going to take forward

## Zooming out — priorities for the project

- @snth thoughts on integrations (below)
- Malloy — @aljazerzen — lots of resources, we really shouldn't try and compete on tooling & UI. Instead we should focus on adding core features to the PRQL lang (such as typing).
- Discussion on project's focus

- Compiler development — @aljazerzen "ask me more questions". "Add a docstring that might be wrong, and I'll correct it"

### Integrations

- @snth — a few integrations are half-done
- evidence.dev
- (a couple of others I didn't catch as the notetaker)
- Superset? (@max likes the idea a lot)
- @snth — some blog posts lined up.

# 2023-03-05

## Who's here & updates

- Max — getting back into Rust, done some PRs, around error messages etc
- Tobias — worked on ducker, blog post on `loop` & ducker. Has added comments, will try and catch up.
- Aljaz — Chumsky is merged! RFC type system. Relative names proposal and code.

## To discuss

https://github.com/PRQL/prql/issues?q=is%3Aissue+is%3Aopen+label%3Aneeds-discussion

- Release
- Yes, 0.6.0
- Switch — re-revert the syntax? Control value.
- Yes re-revert
- Rename to case!
- Do both of these and then revert

# 2023-02-19

## Who’s here & updates

- Max — a couple of releases, lots of triaging, mentoring some contributions
- Rich — not much code, excited for the dev container
- Aljaz — change font, `prqlc watch`, preprocessing of jinja, chumsky parser

## To discuss

- Chumsky — still 100x slower. Improvements are better error messages, unified parsing in rust, error recovery.
- Conclusion: improve performace of chumsky, since there must be something wrong - this cannot be just "chumsky slow"
- Jinja — discussion on #1722, probably we merge because it reduces our surface area a bit. But investing here is probably won't make _that_ much of an impact, given even if it's perfect, not being integrated with dbt is so much of a discount.
- Contributing — not clear on easy wins here. Maybe the compiler is just very hard? Need more info on where folks are dropping out.

# 2023-02-05

## Who’s here & updates

- Max — not so productive (traveling, had COVID), did a slightly different 1 year blog post but would need much more work. Some random PRs / fixes. Lots of triaging. Enthusiastic about increase in contributions.
- Aljaz — less compiler dev, but still some work on intercept & loop. Did some work on website & subsurface talk. No tight plans on what to do next.
- Tobias — did `prql-query`, merged some PRs. Upgrading dependencies would give S3. Going to try and focus on presentation due on 13th

## To discuss

- should we discriminate over dialect versions?
- Current view: where it's possible to compile for old versions, we should target the old version. Where it's not possible, we can compile to the new version. For the moment we don't have a feature for different dialect versions.
- We can have a principle that we accept contributions for dialect implementations where something is either not possible in the generic dialect, or more performant.
- switch syntax
- Agreed as fat / thin arrow
- namespace resolution
- proxy server?
- target / dialect
- Proposal: we should change the compile func to take a `target` rather than `dialect`
- VSCode will have "Preview PRQL"

# 2023-01-22

## Who's here & updates

- Aljaz — working on except & intercept. SQL dialects are painful! Then working on transform ordering guarantees. Then loop.
- Rich — been doing documentation. Cheerleading!
- Max — did a release 0.4.0. Lots of small things. Mentoring some new folks, very happy about that.
- Tobias — release process & docs
- Kasun — Elixir integration

## To discuss

- Versioning / release cycle / playground&book version
- Integrations — what's plan.
- should we discriminate over dialect versions?
- switch syntax

## Minutes

- Branch management
- Introduce `stable` branch which tracks the latest release + hotfixes/tweaks + docs changes,
- Someone to do the work to update the GHAs
- Book & playground are released from stable branch,
- most of PRs are merged into main (including docs of new features),
- we will look into having another release for the main branch published in parallel to current deployment.

- Integrations:
- not really successful so far,
- integrations are a measure of adoption,
- @snth is not concered, adoption is picking up slowly,
- should we fork dbt?
- who is target audience? Programmer-savy data people
- it have `pip install x` thats good enough
- prql plugin that compiles .prql into .sql files that could even be committed (portability)
- fal: dbt pre-run hook

- Blog post

- Opportunity to re-state benefits — "case for PRQL"
- Here's what we've done — stars, integrations
- Here's what we're going to try and do
- Can we get users? bit.io & Marko?

# 2023-01-08

## Who's here & updates

- Tobias - Recursive CTEs
- Rich — versioning
- Marko — can we release *fixes* quicker; do we want the "embedded playground" PR merged/fixed?
- Max
- Paul — would be up for taking the

## To discuss today

- When we release 0.4
- How folks can use PRQL
- Push harder dbt / rill
- Build something of our own
- DataGrip?
- Very open to ideas
- Ways of getting more contributors
- Ruff
- lints, sort of "levels" of contributing

## Using PRQL

Options
- Push harder dbt / rill
- Build something of our own
- DataGrip?
- Very open to ideas

@marko — push on DataGrip, or Pandas/Jupyter

@snth
- could do more marketing around the extensions we have — use the material we built from Normconf
- prqlquery — would like to restart

## New contributors

- Ruff comparison — PRQL is inherently more complex
- Good first issues that seem difficult at first glance
- New contributors – do we have data on the increase of contributors over time? -@marko
- Dialect-specific standard library @marko

## Release

https://github.com/PRQL/prql/milestone/4

Do we do a 0.4 beta?

Tradeoff between a 0.4 now & 0.5 later, vs. 0.4 shortly?

@aljaz — happy with 0.4 & then 0.5. Let's do an anniversary post though! Lots we can talk about — RQ, etc

Anniversary is Jan 24
- @marko — a focus on use-cases in the "anniversary post"
- exploratory analysis in Jupyter
- dbt transformations – a company having their entire processing pipeline using PRQL
- data products (like Supersimple) built on top of it

## Discussion at end

Worth zooming out — are we working on the right things? Worth reassessing the roadmap

"our potential users want a finished language vs a tool they have to integrate into their tooling"

How SQL-specific should we be? How relational-specific should we be?