duckdb-kql 0.0.1.dev1__tar.gz

duckdb_kql-0.0.1.dev1/.gitignore

@@ -0,0 +1,226 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Generated at build time by hatch-vcs from the git tag. Never commit it —
+# a stale copy would silently win over the real version.
+src/duckdb_kql/_version.py
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#   Usually these files are written by a python script from a template
+#   before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+# Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+# uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+# poetry.lock
+# poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+# pdm.lock
+# pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+# pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# Redis
+*.rdb
+*.aof
+*.pid
+
+# RabbitMQ
+mnesia/
+rabbitmq/
+rabbitmq-data/
+
+# ActiveMQ
+activemq-data/
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#   JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#   be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#   and can be added to the global gitignore or merged into this file.  For a more nuclear
+#   option (not recommended) you can uncomment the following to ignore the entire idea folder.
+# .idea/
+
+# Abstra
+#   Abstra is an AI-powered process automation framework.
+#   Ignore directories containing user credentials, local state, and settings.
+#   Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#   Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore 
+#   that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#   and can be added to the global gitignore or merged into this file. However, if you prefer, 
+#   you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+# Temporary file for partial code execution
+tempCodeRunnerFile.py
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# Streamlit
+.streamlit/secrets.toml
+
+# duckdb-kql
+.antlr/
+tests/cases/**/unparsed.json

duckdb_kql-0.0.1.dev1/CODE_OF_CONDUCT.md

@@ -0,0 +1,71 @@
+# Code of conduct
+
+## Our pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, caste, color, religion, or sexual
+identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our standards
+
+Examples of behavior that contributes to a positive environment:
+
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+- Focusing on what is best not just for us as individuals, but for the overall
+  community
+
+Examples of unacceptable behavior:
+
+- The use of sexualized language or imagery, and sexual attention or advances of
+  any kind
+- Trolling, insulting or derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or email address,
+  without their explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement responsibilities
+
+Project maintainers are responsible for clarifying and enforcing our standards
+of acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Maintainers have the right and responsibility to remove, edit, or reject
+comments, commits, code, issues, and other contributions that are not aligned to
+this Code of Conduct, and will communicate reasons for moderation decisions when
+appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the maintainers through
+[GitHub's private reporting](https://github.com/mmaitre314/duckdb-kql/security/advisories/new)
+or by opening an issue if the matter is not sensitive. All complaints will be
+reviewed and investigated promptly and fairly.
+
+Maintainers are obligated to respect the privacy and security of the reporter of
+any incident.
+
+## Attribution
+
+This Code of Conduct is adapted from the
+[Contributor Covenant](https://www.contributor-covenant.org), version 2.1,
+available at
+https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.

duckdb_kql-0.0.1.dev1/CONTRIBUTING.md

@@ -0,0 +1,195 @@
+# Contributing
+
+Thanks for looking. This project has one unusual rule, and most of what follows
+is a consequence of it.
+
+> **A wrong answer is worse than no answer.** KQL and SQL look alike in places
+> where they behave differently, so a mapping that is *nearly* right runs
+> cleanly and returns numbers nobody questions. Every mapping here is verified
+> against the real KQL engine, and anything that cannot be verified raises
+> instead.
+
+## Getting set up
+
+```bash
+git clone https://github.com/mmaitre314/duckdb-kql
+cd duckdb-kql
+pip install -e ".[dev]"
+pytest
+```
+
+A dev container is included (`.devcontainer/`) if you would rather not install
+Docker, DuckDB and the emulator yourself.
+
+Before opening a pull request:
+
+```bash
+ruff check src tools tests
+mypy
+pytest
+```
+
+All three run in CI on every pull request.
+
+## Adding a mapping
+
+Most contributions are one KQL function or operator. The shape is the same each
+time:
+
+1. **Find the ground truth.** Run the construct on the Kusto Emulator and record
+   what it actually returns — including the edge cases (null input, empty
+   string, out-of-range index, negative number). `docs/oracle-harness.md`
+   explains how to run it. Do not infer behaviour from Microsoft's docs; several
+   of the divergences already recorded here contradict them.
+2. **Add a registry row.** Mappings are data, not code:
+   `src/duckdb_kql/translate/functions.py` holds one row per construct, citing
+   the `R`-rules it must honour. If your mapping needs a shape a `{0}`-style
+   template cannot express, add a special form in `translate/__init__.py` and
+   say why in a comment.
+3. **Write the trap test.** Not "it returns something" — the specific case where
+   the obvious mapping would be wrong. If you cannot think of one, look harder:
+   `docs/TRANSLATION.md` §4 lists twelve places the two languages diverge.
+4. **Regenerate the support matrix.**
+
+   ```bash
+   python tools/gen_support_matrix.py
+   ```
+
+   `docs/kql-support.md` is generated and CI fails if it is stale. Fill in the
+   `Limitations and gotchas` cell with what you learned in step 1 — that column
+   is the point of the document.
+5. **Update the baselines** if coverage moved:
+   `tests/test_behavior.py::BASELINE_PASSING` and
+   `tests/test_profile_azure_monitor.py::BASELINE_SUPPORTED` may only go up.
+
+## When *not* to add a mapping
+
+Refusing is a valid, and sometimes the correct, outcome. Add the construct to
+the refusal list in `tools/gen_support_matrix.py` with a reason if:
+
+- the nearest DuckDB function is a *different* function that returns
+  plausible-looking output (`hash_xxhash64` → DuckDB's `hash`);
+- the precision or algorithm cannot be matched (`datetime_part('nanosecond')`,
+  the `hll` and `tdigest` sketch formats);
+- it would require network or code execution (`geo_location`, the plugins).
+
+A refusal with a reason is a contribution. A mapping that is 95% right is a bug
+report waiting to be filed against someone else's report.
+
+## Things CI will check that are easy to miss
+
+| Check | Why |
+|---|---|
+| `docs/kql-support.md` regenerates identically | The support table must not be able to say something the code does not do. |
+| The documented request-option table matches `OPTION_SUPPORT` | Same reason, for the Kusto client. |
+| Layer 0 installs and works with `duckdb` absent | The layering claim is only true if it is tested. |
+| The CLI does not import `duckdb` | Build-time translation is meant to run in a minimal CI image. |
+| Links in the docs resolve | Including the absolute ones the README uses for PyPI. |
+| A consumer's type checker sees real types | The package ships `py.typed`, so `Any` in a public signature is a promise broken silently. `tests/test_typing.py` checks from the outside; `mypy` alone cannot. |
+| The committed parser matches `grammar/Kql.g4` | The generated parser is committed so installs need no Java. |
+
+## The emulator
+
+The acceptance suite compares against the Kusto Emulator, which runs in Docker.
+It is a **development and CI tool only**: never a runtime dependency, never
+redistributed, never exposed as a service. Per its licence, do not publish
+timing or performance numbers measured against it. See `docs/licensing.md` §5.
+
+Contributions that only touch translation logic do not need it — the frozen
+corpus in `tests/cases/` carries the expectations it produced. You need the
+emulator when you are adding a mapping and have to *establish* an expectation.
+
+## Reviewing a change
+
+Reviews here are checklist-led and organized by area, because the dangerous
+change in this project is the one that runs cleanly and returns a *plausible
+wrong answer*. [`docs/code-review/`](docs/code-review/README.md) is the
+framework: a charter (severity scale, reporting format, and the small-diff /
+checklist discipline the literature backs) plus one checklist per area of the
+codebase — translation correctness, public API & typing, security & injection,
+the Kusto client, testing & the oracle, and tooling/packaging/CI/docs. Reviewing
+a change means picking the area(s) it touches and working its list; the
+[`adversarial-reviewer`](.claude/agents/adversarial-reviewer.md) agent automates
+the translation-correctness pass over a mapping diff.
+
+## Style
+
+Match the surrounding code. Two habits worth copying:
+
+- **Comments explain the trap, not the mechanism.** `# KQL weeks start Sunday;
+  date_trunc('week') starts Monday` is worth writing. `# truncate the date` is
+  not.
+- **Tests are named after what would break.** `test_payload_never_reaches_the_sql_text`
+  says what is being protected; `test_parameters` does not.
+- **`Any` is declared, not defaulted.** The package is fully typed and ships
+  `py.typed`. Where a value genuinely has no type — an ANTLR tree node, a
+  `dynamic` document — say `Any` and say why in a comment. An unannotated
+  function silently becomes `Any` for every caller, which is the same failure
+  mode as a wrong answer: it looks fine.
+
+## Reporting a wrong answer
+
+The most valuable bug report for this project is a query that runs and returns
+something different from Kusto. Please include the KQL, the result you got, the
+result Kusto gave, and — if you have it — the output of:
+
+```python
+duckdb_kql.to_sql(your_query)
+```
+
+Security issues go through [SECURITY.md](SECURITY.md) instead, not the public
+tracker.
+
+## Releasing (maintainers)
+
+**The git tag is the version.** There is no file to bump: `hatch-vcs` reads the
+tag at build time and writes it into the distribution, so the tag and the package
+cannot disagree.
+
+Publishing is automated but deliberately not automatic — only a **published
+GitHub Release** uploads to PyPI. A tag on its own builds and checks; it does
+not publish, so a bad tag costs nothing.
+
+The whole procedure:
+
+1. Go to **Releases → Draft a new release**, create the tag `vX.Y.Z` on `main`,
+   click **Generate release notes**, and publish.
+
+That is it. The release workflow builds the sdist and wheel, verifies the built
+version equals the tag, smoke-tests the wheel in a clean environment, uploads to
+PyPI via [Trusted Publishing][oidc], and attaches the artifacts to the release.
+
+Two things worth doing around it:
+
+- **Rehearse with a manual run** for a first release, or after any packaging
+  change: *Actions → Release → Run workflow*. That does everything except
+  publish — build, metadata check, and the clean-environment smoke test of the
+  wheel — so a packaging break surfaces without spending a version number. The
+  same build also runs on every push and pull request.
+
+- **Edit the generated notes** before publishing. There is no `CHANGELOG.md`;
+  the release notes and the git history are the record. *Generate release notes*
+  gives you the list of commits, which is a fine skeleton and a poor explanation
+  — so lead with a short paragraph on what changed for the people using the
+  package, especially anything that returns a different answer than it did
+  before. This is the reason commit messages here are written to be read.
+
+**Before the very first release**, two one-time setup steps that only an owner
+can do:
+
+1. Register the PyPI publisher (a *pending* publisher, since the project does not
+   exist yet) at <https://pypi.org/manage/account/publishing/>: owner
+   `mmaitre314`, repository `duckdb-kql`, workflow `release.yml`, environment
+   `pypi`.
+2. Create the `pypi` environment under **Settings → Environments**. The name
+   must match the publisher registration, because PyPI checks the environment in
+   the OIDC claim. Adding yourself as a required reviewer on it makes every
+   upload a deliberate two-step action.
+
+## Licensing
+
+Contributions are accepted under the MIT licence in [LICENSE](LICENSE). If you
+vendor anything third-party, add it to
+[THIRD-PARTY-NOTICES.md](THIRD-PARTY-NOTICES.md) and check
+[`docs/licensing.md`](docs/licensing.md) for how the existing entries are
+handled.

duckdb_kql-0.0.1.dev1/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Matthieu Maitre
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.