Pietto 0.1.5 public alpha

Pietto 0.1.5 public alpha

Pietto 0.1.5 is the first release whose compiler reads only the modern source
syntax. It is closer to Python: None/True/False, T and T | None,
source name: Shape = ..., single-line clauses without a colon, and
any(... for row in relation). It also ships the single-file JOIN support
and the compiler fixes made after 0.1.4. Source files written for 0.1.4 must be
converted with pietto migrate (see "Upgrading" below). Pietto is still an
alpha, and its CLI never connects to a database.

Highlights

• A bare type is never None. T is a value that is never None, and
  T | None is a value that may be None. T not null and T nullable are
  retired.
• Python-style literals and declarations. None, True and False
  replace null, true and false. A source is declared as
  source orders: Order = postgres.table("orders"). Clauses with one item
  take no colon, as in where 100 <= amount <= 500, group by customer_id
  and having n > 1. Each name gets its own let. A relationship predicate
  has typed rows:
  relationship OrderCustomer(order: Order, customer: Customer): ....
• select and order by read the names you defined. select may list a
  let name. Outside a grouped query, order by may name a SELECT output. A
  bare name that is both an input field and a different output is now an
  ambiguity error (PIE-S2102). Pietto never silently picks one.
• any / not any replace semi join / anti join. Write
  where any(predicate for row in relation) or where not any(...). The SQL
  is the same correlated EXISTS / NOT EXISTS. The whole-relation
  exists name is unchanged.
• Named windows come before select. Declare a window as
  let w = window(...) with the other lets. Windows share the let
  namespace.
• One-line forms. enum Status: active, suspended. A def,
  relationship, constraint or derive body may follow its header on the
  same line. qualify: lines are joined with and.
• Diagnostics teach the modern spelling. Each retired spelling is
  PIE-P1000, and its message gives the exact rewrite. JSON output also
  carries the rewrite as suggestion. The fan-out remedies of PIE-S2381 and
  PIE-S2333 no longer suggest grouping by a unique key, which would change
  the result's grain.
• A warning when a file reads its own table or query. A from, a JOIN or
  an any(...) before a later JOIN that reads a table or query of the same
  file reads it by name in single-file SQL, so the SQL runs only where the
  database already has a relation of that name. Each such read is now a
  PIE-S2382 warning in every check mode. Any other any(...) defines the
  relation it reads as a CTE and has no warning. The emit-sql text output
  is unchanged.
• Single-file JOINs. check and PostgreSQL emit-sql accept INNER, LEFT,
  RIGHT, FULL and CROSS JOINs and any/not any filters over the sources,
  tables and queries of one file. Name each JOIN input with let and give
  every JOIN except CROSS an on. MySQL emit-sql refuses each JOIN relation
  (PIE-B1000) and still emits the file's other SQL. explain refuses JOIN
  relations (PIE-I1000). An aggregate other than count() must not read
  rows that a JOIN may repeat (PIE-S2381). A relationship call that matches a
  declared unique key proves that rows are not repeated. See
  single-file JOINs.

Upgrading a 0.1.4 file: pietto migrate

pip install -U pietto
pietto migrate old.pietto > migrated.pietto
pietto check migrated.pietto

migrate never edits its input. When the result passes the modern parser, it
writes one complete file to stdout. Otherwise it exits 1, writes nothing to
stdout, and reports PIE-P1011 at each place that needs your decision, in
source order. It keeps comments, strings, line endings and a leading BOM.

Its rewrites include:

• T not null becomes T.
• T nullable and a bare T become T | None. This never claims a value is
  non-null, so remove each added | None where the column really is never
  NULL.
• null/true/false become None/True/False.
• A let: block becomes one let per name.
• cast(x as Float) becomes Float(x).
• satisfying: becomes having.
• A named window declared after select moves before it.

It asks for a manual rewrite (PIE-P1011) of every 0.1.4 JOIN written with
as, including semi join and anti join, and of every source-bound
relationship with endpoints. A pietto NUMBER header does not select a
syntax, and no flag restores the old one. Compiled bundles and saved-job
records are not source and are not migrated. The full list is in
Upgrading a 0.1.4 file.

Compatibility

• Old source is refused. A 0.1.4 file that uses a retired spelling fails
  with PIE-P1000 until it is migrated.

• schema_version = 1 relationship JOINs are no longer available. In
  0.1.4, a legacy-flat project (schema_version = 1) checked relationship
  JOINs written with as, and JOINs via a relationship. Now such a project
  checks no JOIN and no any(...) of the current syntax. Each JOIN, of any
  kind, is one PIE-S2334 at its on, including a relationship call, or at
  the JOIN when it has no on. Each any(...), nested or not, is one
  PIE-S2334 at the any(...). They come in source order, and the messages
  name the way forward (JOIN customer: a schema_version = 1 project has no JOIN in the current syntax; set schema_version = 2 to check it. and
  any(...): a schema_version = 1 project has no any(...) in the current syntax; set schema_version = 2 to check it.). 0.1.4 refused this spelling
  of JOIN and any(...) with PIE-P1000, so this refusal removes nothing
  that 0.1.4 accepted. To check such a project:

  1. Rewrite the JOINs and relationships in the modern spelling.
  2. Set schema_version = 2.
  3. In a project of several files, import and export what each module reads,
     and declare each relationship in the module that uses it.

  A legacy-flat project never emitted SQL, so no SQL changes. See
  legacy-flat projects.

• Some programs that 0.1.4 accepted are now refused, and some emit
  different SQL. This includes the fixes made after 0.1.4, for example
  RIGHT/FULL JOIN aggregates that could count a row twice. The
  release notes
  give each change.

• Bundles and saved jobs made by 0.1.4 or earlier are refused by the
  changed code identity. Keep their matching old environment. Pietto does not
  rewrite them.

• 0.1.5 is a normal version number. pip install -U pietto upgrades to
  it, and so do the pins pietto~=0.1 and pietto<0.2. To stay on the 0.1.4
  syntax, pin pietto==0.1.4.

Fixes

• check --project no longer stops with an internal error on a comparison
  chain such as 0 < low + 1 <= high < 10, also over a window in QUALIFY.
  emit-sql --project emits a chain as it emits the same comparisons joined
  with and, and so does single-file emit-sql for a chain over an
  any(...). An error in an operand that two comparisons of a chain share is
  reported once by check --project of a schema_version = 2 project, as the
  next item states, and, in the cases this release fixes, in a single file and
  in a schema_version = 1 project.
• check --project of a schema_version = 2 project reports a diagnostic
  equal to an earlier one in code, severity, message, location and suggestion
  once, at its first position, as the project JSON v2 contract states. 0.1.4
  repeated an error in a call inside another def's body as often as the
  called def's expansion made it, and a query parameter passed to a def and
  read in a position that refuses it (PIE-S2355) at each use of the
  argument. A single file still reports such an error in a def body as often
  as the expansion makes it, except anywhere in an operand that a comparison
  chain copies, such as x in 0 < x < 10, where it is reported once. The
  value of an inclusive chain lower <= value <= upper is not itself copied,
  so its error still follows the expansion unless the error lies in copied
  operand text, either around that chain or nested in its value.
• An explicit-module project refuses an aggregate inside an any(...)
  predicate (PIE-S2335), as a single file does.
• An enclosing any binder hides the relations of its name from a nested
  any(...) also before a later JOIN and in explicit-module projects, where
  such a read was accepted and could read the wrong table (PIE-S2301). A
  binder hides only the name as written, so a nested any over a let alias
  of a relation with the binder's name is now accepted.
• Single-file SQL emission refuses a scalar any(...) reader whose CTE would
  hide a table that the same SQL reads without a schema (PIE-B1000); the SQL
  read the CTE in place of the table.
• The private combined-IR verifier refuses a scalar any read of an outer
  input that names another relation, or other field names or another
  nullability than that input has.
• In a single file, a JOIN without on whose FROM input or target is a table
  or query of the same file reports PIE-S2335, as every other JOIN without
  on does.
• A relationship call that passes a table of the same file to a shape
  parameter (PIE-S2604) in a file that selects a window function no longer
  stops check, explain and emit-sql with an internal error.
• A schema_version = 1 project resolves let name = value as a single file
  does. It reports one PIE-S2334 per JOIN and per any(...), in source
  order: an ...

Pietto 0.1.4 public alpha

Pietto 0.1.4 public alpha

This release makes Pietto source read more like Python, adds one-line
relationships, inferred JOIN sources and inline def functions, and fixes
compiler and CLI defects found after 0.1.3. Source that 0.1.3 parsed keeps
parsing as before, with one exception: a file whose first code line is
indented is now PIE-P1000.
Some programs that 0.1.3 accepted are now refused because their SQL would fail
or mean something else; see Compatibility. Pietto remains an alpha; the CLI
does not execute database queries.

Highlights

• Python-style layout. select:, select distinct:, group by:,
  order by:, partition by:, the row let: and enum NAME: take their
  items after : on the header line, separated by commas, or in an indented
  block whose lines each hold one item or a comma-separated list, for example
  order by: ordered_at desc, id desc. where:, satisfying: and a shape's
  check NAME: take one condition after : or one condition per line of an
  indented block; the lines are joined with and, each as if written in
  parentheses. Inside parentheses an expression can continue over several
  lines; there is no backslash continuation, and an unclosed ( is PIE-P1008.
  These forms parse to the same tree as the one-item-per-line form or the
  and chain, so checks and SQL are unchanged.
• Soft keywords as names. 26 words, among them type, source, from,
  where, select, query, limit and check, may also name a shape field,
  a select output, a row let: binding, a parameter or a typed VALUES
  column, as in where type == "click". They do not name declarations or
  relations. and, or, not, null, true, false, between, like,
  nullable and window stay reserved.
• One-line relationships. relationship r: a.x == b.y, with one or more
  and-joined equalities between fields of two different relations, declares
  the endpoints a and b, so its roles are the relation names. A
  relationship of a relation to itself keeps the block form.
• Shorter relationship JOINs. A JOIN that follows a declared relationship
  needs only its header; its from line and VIA roles are optional, and the
  header may carry one step: : from b, : via r or : via r: s -> t. In an
  explicit-module project (schema_version = 2) a JOIN without from uses the
  one earlier binding that has a relationship to its target, in exactly one
  usable direction. No candidate is preferred: otherwise PIE-S2333 at the JOIN
  names every candidate. A JOIN with on and a CROSS JOIN still name their
  source with from (PIE-S2378). Single-file and schema version 1 project
  checks do not infer.
• Inline def functions. def f(p: T not null) -> R nullable: return e
  names a reusable scalar expression over Bool, Int, Float, Decimal,
  Text, Date, Timestamp or UUID parameters with explicit nullability.
  It is checked once where it is declared, and each call is replaced by its
  body before the call site is checked, so a call emits exactly the SQL of the
  same expression written by hand; no database function is created. A def
  belongs to its module (no import or export), recursion is refused, and an
  error inside a call is reported once however often the body uses the
  argument, except in a call written inside another def's body, where an
  error other than an argument mismatch (PIE-S2395) is reported as often as
  its expansion makes it, and in two project cases (see Known limitations).
  An error in a def body stops the check before semantic analysis: of its
  file, and in a project of every module. Available in single files and
  explicit-module projects.
• New diagnostics: PIE-P1008 (an unclosed (), PIE-S2378 (a JOIN with
  on or a CROSS JOIN without from), PIE-S2379 (def in a schema version 1
  project), PIE-S2395 to PIE-S2399 (def arguments, recursion, forms, names
  and expansion size), PIE-S2380 (an ORDER BY key a target would misread) and
  PIE-S2604 (a relationship on operand error).

Compatibility

• Bundles and saved jobs made by 0.1.3 or earlier are rejected by the 0.1.4
  code identity. Pietto neither migrates nor rewrites those bytes; use their
  matching old environment, then compile again for 0.1.4. Format markers are
  unchanged. The VS Code extension 0.1.0 accepts only the 0.1.2 wheel or its
  baseline fingerprint and refuses 0.1.4. This release adds no stable editor
  API.
• Explicit-module projects:
  • A field of an enum, or of an alias of one, is typed as that enum, as in a
    single file, and a def parameter the field does not fit is PIE-S2395.
    Programs 0.1.3 accepted are refused: where status (PIE-S2202),
    status in ("active") and status not like "a%" (PIE-S2105), and
    lower(status) and coalesce(status, "x") (PIE-S2104). Programs 0.1.3
    refused pass check --project: with JOIN inputs, a selected let: name
    bound to an enum field (0.1.3: PIE-S2333), a JOIN on that compares enum
    fields (PIE-S2334 and PIE-S2335) and a JOIN over a relation let that
    outputs one (PIE-S2333); without them, select distinct of an enum field
    and a grouped satisfying that compares one (PIE-S2333), a window or
    QUALIFY partitioned or ordered by one (PIE-S2103 Unknown function), and
    lag, lead, first_value, last_value and nth_value of one
    (PIE-S2104 value type must be concrete). The other JOINs over a source
    with an enum field, on which 0.1.3 crashed with a ValueError traceback
    (see Included repairs), pass when they select, group, order, compare or
    window the field, and count(c.status) there is PIE-S2314.
    emit-sql --project still blocks every table or query that reads a
    source with an enum field (PIE-B1003). Some enum reads still fail closed
    with PIE-S2333 (see Known limitations).
  • A LIKE pattern read through a let: name of a relation with JOIN inputs
    and ending in an unpaired ! is PIE-S2105, where 0.1.3 emitted a
    VERIFIED LIKE ... ESCAPE '!' that PostgreSQL rejects.
  • The WHERE of a relation with a let: binding of unknown type, such as
    k = null, or with an error in a binding is checked as in a single file,
    except in a select distinct relation or one with QUALIFY (see Known
    limitations): where n == k is PIE-S2105, where 0.1.3 passed check and
    emit-sql --project blocked the relation with PIE-B1003, and a def
    argument there that does not fit is PIE-S2395.
  • A relation reports the errors of each let: binding, of its WHERE and of
    its SELECT items, in source order, where 0.1.3 reported only the first
    part that failed: the first failing SELECT item hid the others, an error
    in any relation's let: hid its WHERE, and an error in a JOIN relation's
    let: hid its WHERE and SELECT errors. After such an error in a JOIN
    relation's let:, its WHERE and, without GROUP BY or aggregates, each
    SELECT item that is no window report their own errors when they read no
    relation (exists, scalar or in), no binding with an error of its
    own and no field that does not resolve; any other SELECT item, such as a
    grouped or aggregate one, still reports none. Without JOIN inputs, the
    SELECT items of a select distinct relation and an aggregate argument a
    project refuses still report no error of their own (see Known
    limitations).
  • Beside a binding of unknown type or with an error, the other bindings keep
    their types: with k = null, f = id and h = f, v = h passes, where
    0.1.3 reported PIE-S2102 Unknown field: h, and a window that reads no
    binding, also through the named window it uses, is analyzed, where 0.1.3
    reported PIE-S2103 Unknown function for every window there. A selected
    read of k itself takes its type from where it stands, as in a single
    file, so v = coalesce(k, 1) and v = 1 if k else 2 pass
    check --project where 0.1.3 reported PIE-S2102 Unknown field: k;
    emit-sql --project still blocks such a relation (PIE-B1003). A window
    that reads a binding there fails closed with the binding's error or
    PIE-S2333.
  • With JOIN inputs, a let: binding of unknown type is written into a later
    binding's def argument and null test, as without them: with k = null,
    w = coalesce(k, o.id) and v = tnn(w) for a Text not null parameter,
    v is PIE-S2395. A read of such a binding is typed as without JOIN inputs
    too, so a later binding, SELECT item or WHERE that is ill-typed only then
    reports its error: with j = coalesce(k, 1), d = len(j) is PIE-S2104
    where 0.1.3 reported a bare PIE-S2333; with nothing ill-typed, such a
    relation still fails closed with PIE-S2333. A let that renames a field,
    such as g = r.n with group by: g, selects that field's group key, so
    k = g passes and emits where 0.1.3 reported PIE-S2102; another let:
    name selected from the groups is PIE-S2333 instead of PIE-S2102.
  • In a relation with JOIN inputs, a null literal compared or combined in
    satisfying:, also as a nullable def argument, is PIE-S2327 at the
    literal, and any other predicate of unknown type is PIE-S2333, where 0.1.3
    crashed with a ValueError traceback.
  • emit-sql --project reports an ORDER BY key with a part of unknown type,
    such as (null is null), BLOCKED with PIE-B1003 order, where 0.1.3
    reported INPUT_REJECTED Invalid current planning roots. (exit 2). A
    plan whose let: stages carry more columns than half the generated-node
    limit is BLOCKED with PIE-B1007 generated_structure_limit once the
    contract is read, before it is assessed and realized, beside no other
    blocker than a premise conflict: a 300-binding chain is refused in
    seconds instead of about a minute.
  • A GROUP BY over a table or query that is one global aggregate row, such
    as a table that selects only `c...

Pietto 0.1.3 public alpha

Pietto 0.1.3 public alpha

This release extends explicit-module (schema_version = 2) projects with
composable named relations and checked query values. Pietto remains an alpha;
the CLI does not execute database queries.

Highlights

• Relation lets provide local FROM-, set-, or typed-VALUES relations that emit
  as ordered named CTEs.
• Entry queries can declare typed, nullable or non-null named parameters.
  PostgreSQL reuses a parameter placeholder; MySQL emits one placeholder per
  read in rendering order.
• Typed VALUES bodies, exists, scalar, in, and not in relation reads
  are available in their documented ungrouped positions.
• Correlated reads retain outer-row identity and multiplicity; INNER, CROSS,
  and LEFT LATERAL joins follow their documented join semantics. Bounded
  generate_series is supported on PostgreSQL.
• The explicit Python execution API accepts the new admitted forms on its
  selected routes, while saved-result recovery (R2) continues to reject forms
  without its required coordinate basis.

Compatibility

Bundles and saved jobs made by 0.1.2 are rejected by the 0.1.3 code identity.
Pietto neither migrates nor rewrites those bytes; use their matching old
environment, then compile again for 0.1.3. The VS Code extension 0.1.0 accepts
only the 0.1.2 wheel or the 9e74aa68 baseline fingerprint and refuses 0.1.3.
This release adds no stable editor API.

Boundaries

• The release target is compiler and package coverage on CPython 3.12 and 3.13
  for Linux x86-64. The support boundary is established by formal acceptance of
  the actual distribution bytes.
• Native-route evidence is limited to CPython 3.13.13 on the qualified
  integration host with the lock's exact artifacts. Other native platforms,
  Python versions, database releases, and driver closures are not claimed.
• A VALUES-only statement is PostgreSQL-only; MySQL refuses it. PostgreSQL-only
  table functions are limited to bounded pg_catalog.generate_series.
• A correlated scalar, in, or not in read with ORDER BY and LIMIT is
  PostgreSQL-only; MySQL rejects that shape. R2 rejects relation reads,
  correlated reads, LATERAL joins, VALUES, and table functions before workspace
  access where no permitted recovery basis exists.

Published bytes are never overwritten. A later defect is addressed in a later
version; any PyPI yank remains an owner action.

Pietto 0.1.2 public alpha

Phase69 public alpha release notes — 0.1.2

These notes describe 0.1.2. Its versioned GitHub pre-release and PyPI listing
determine release availability. The historical 0.1.1 wheel and v0.1.1
assets are not replaced.

Public alpha API

• pietto.execution exposes explicit postgres_rows for PostgreSQL 18.6,
  mysql_rows for MySQL 8.4.12, and postgres_adbc for PostgreSQL 18.6.
  Each route uses its selected pinned dependency closure and never falls back to
  another route.
• Results use caller-owned Arrow batches and terminal outcome facts.
  UNKNOWN, REMOTE_QUIESCENCE_UNCONFIRMED, and remote-unobserved cleanup are
  not acknowledgements. ResultHandle.cancel() may be requested by a
  controller thread; it returns None, while the outcome retains the observed
  cancellation, transaction, and cleanup facts.
• Query bundles carry caller-held content, producer, and compatibility records.
  They are snapshots: source edits need a new compilation. Bundle loading and
  every execution attempt check current code identity. Bundle trust records
  are checked at load time; each execution needs fresh access and deployment
  premises.
• v7 saved workspaces provide ordinary save, R1 source-free re-read,
  fixed-snapshot verified export, R2 same-source recovery, local publication,
  narrow caller-owned unpublished-generation retirement, and relay to the
  local reference cooperative sink. inspect_job() is read-only recorded
  metadata and grants none of those authorities.
• The API remains alpha. Names, fields, error codes, and behavior may change
  in later alpha releases; existing compiler and CLI contracts remain separate.
  The CLI still has no database-execution command.

Compatibility and retained data

The installed Pietto and ANTLR code identity is checked for compile, bundle
load, and execution. The 0.1.2 version update changes the CLI fallback version,
and the wider source tree can also change that identity. A bundle or saved-job
record made under 0.1.1 can therefore be refused under 0.1.2. Pietto
preserves the original bytes and does not migrate them; use the matching old
environment when the old state must remain usable.

Support and durability limits

Only CPython 3.13.13 on Linux x86-64, with the lock's exact artifacts on the
qualified integration host, has native evidence for all three routes. Windows
native execution is NOTRUN; offline Windows compiler-project checks do not
establish job, database, or platform support.

Public save creates v7 only, with no migration. A workspace permits one
coordinator at a time and refuses concurrent capture, recovery, or relay with
RUNTIME_BUSY. There is no public scheduler, general garbage collector,
age-based deletion, or general directory cleanup. retire_generation removes
only the caller-owned unpublished generation's latest-checkpoint root; it does
not delete files. Publication-owned retention is permanent.

R1 and verified export are source-free reads with compatible code, fresh
caller-held scalar trust, integrity, and reader protections. R2 is live
same-source recovery: it requalifies one caller-supplied compiled-source
requirement for every source in compiled order, including guarded and refined
sources. A saved close only resumes or awaits bounded cleanup; until it
settles, remote state is UNKNOWN and no acknowledgement is claimed.

Included compiler and CLI repairs

• A single leading UTF-8 BOM is ignored without changing parsed AST or source
  locations; a second or non-leading BOM remains invalid, and the original
  UTF-8 byte budget still applies.
• When the terminal cannot encode CLI output, Pietto preserves the terminal's
  configured encoding and returns the established clear output-encoding error
  instead of silently replacing source or diagnostic text.
• A single-file relation name may be table or schema.table (MySQL uses the
  database position); each component is quoted independently. Empty components
  and names with more than one dot fail closed with PIE-S2306.
• Cross-family comparison operands fail closed with PIE-S2105; there is no
  implicit conversion. This does not change the existing SQL three-valued
  behavior for comparisons with null.

Attribution and release boundary

THIRD_PARTY_NOTICES.md records unbundled runtime and execution dependencies
and separates wheel/sdist material from the GitHub source archive.
LICENSES/SOURCES.md records the retained original-text provenance. This is
an attribution record, not a legal conclusion.

Before publication, the release stage must inspect the exact accepted wheel,
sdist, and source archive against those per-channel notices. Independent
rebuilds may verify the accepted bytes but never replace them.

Pietto 0.1.1 public preview

Pietto 0.1.1 is a packaging-only update of the 0.1.0 public preview, prepared
for PyPI: the compiler and CLI are the same as in 0.1.0, and the package now
carries the information PyPI needs.

Changes since 0.1.0

• Package metadata: project URLs (homepage, repository, documentation,
  issues, releases), classifiers (Development Status :: 2 - Pre-Alpha) and
  keywords. The license metadata is unchanged (License-Expression: MIT).
• README, which is also the PyPI project description: installation with
  pip install pietto, repository links made absolute and pinned to the
  v0.1.1 tag so that they also work on PyPI, and a short Direction section
  listing goals (not promises or dates) that links the current roadmap. The
  quick start drops its optional header lines and uses
  postgres.table("users"); the previous postgres.table("public.users")
  compiled to the single quoted identifier "public.users", not to a
  schema-qualified table.
• Source: apart from the version number, the only change since 0.1.0 is in
  private execution code that the public compiler, CLI and Python API do not
  reach: two private PostgreSQL execution routes run generated
  result-refinement pages with JIT turned off for the rest of their
  transaction, and read the setting back before each page.

What you can try

• Write readable, indentation-based .pietto sources: typed shapes, sources,
  tables, queries, computed fields, aggregates, grouping and bounded windows.
• pietto check and pietto explain: deterministic parser, semantic and
  backend diagnostics with source locations where the relevant stage has them,
  text or JSON output.
• pietto emit-sql: deterministic PostgreSQL SQL, and MySQL SQL through
  explicit CLI lowering.
• Explicit projects (pietto.toml): project checking, and emit-sql --project
  for one selected table or query with an explicit emission contract,
  producing the versioned pietto.sql-emission.v1 artifact.
• Python: pietto.sql.emit_postgres_sql and the existing public exports.

The public compiler and CLI never connect to a database; run the SQL they
emit in your own database.

Install

CPython 3.12 or later, in a fresh virtual environment (replace python3.12
with your interpreter):

python3.12 -m venv pietto-env
pietto-env/bin/python -m pip install pietto==0.1.1
pietto-env/bin/pietto --version

Or install the wheel attached to this release:

pietto-env/bin/python -m pip install "https://github.com/MianliWang/pietto/releases/download/v0.1.1/pietto-0.1.1-py3-none-any.whl"

Verify downloaded files with sha256sum --ignore-missing -c SHA256SUMS.
GitHub's automatic "Source code (tar.gz)" archive downloads under the same
name as the sdist, pietto-0.1.1.tar.gz, but it is a snapshot of the
repository and is not listed in SHA256SUMS.

Scope and limits

• This is a preview. The public contracts listed in the README (CLI JSON v1,
  diagnostic codes, Project JSON v2, Semantic metadata artifact v1, the project
  configuration and the golden fixture policy for byte-exact SQL output),
  together with pietto.sql-emission.v1, pietto.emission-contract.v1 and the
  public pietto.sql.emit_postgres_sql emitter, follow their documented
  compatibility rules; other behavior may change in later previews.
• Database execution and result APIs are not public yet. The execute-*
  extras install PyArrow and one route's pinned drivers, for private code
  paths only.
• Verified with CPython 3.12 and 3.13 on Linux x86-64. Other platforms and
  Python versions are not covered by this evidence.

License

MIT. Third-party material in the wheel, the sdist and the source archive is
listed in THIRD_PARTY_NOTICES.md, with the original license texts in
LICENSES/.

Release artifacts

The wheel and sdist below are the exact bytes that were built once and
accepted; the PyPI upload of 0.1.1 uses these same two files. SHA256SUMS
lists their SHA-256 digests.

Pietto 0.1.0 public preview

Pietto 0.1.0 is the first public preview of Pietto, a gradual,
semantic SQL authoring DSL with deterministic compilation to PostgreSQL and
MySQL SQL.

What you can try

• Write readable, indentation-based .pietto sources: typed shapes, sources,
  tables, queries, computed fields, aggregates, grouping and bounded windows.
• pietto check and pietto explain: deterministic parser, semantic and
  backend diagnostics with source locations where the relevant stage has them,
  text or JSON output.
• pietto emit-sql: deterministic PostgreSQL SQL, and MySQL SQL through
  explicit CLI lowering.
• Explicit projects (pietto.toml): project checking, and emit-sql --project
  for one selected table or query with an explicit emission contract,
  producing the versioned pietto.sql-emission.v1 artifact.
• Python: pietto.sql.emit_postgres_sql and the existing public exports.

The public compiler and CLI never connect to a database; run the SQL they
emit in your own database.

Install

CPython 3.12 or later, in a fresh environment (replace python3.12 with your
interpreter):

python3.12 -m venv pietto-env
pietto-env/bin/python -m pip install "https://github.com/MianliWang/pietto/releases/download/v0.1.0/pietto-0.1.0-py3-none-any.whl"
pietto-env/bin/pietto --version

Verify downloaded files with sha256sum --ignore-missing -c SHA256SUMS.
GitHub's automatic "Source code (tar.gz)" archive downloads under the same
name as the sdist, pietto-0.1.0.tar.gz, but it is a snapshot of the
repository and is not listed in SHA256SUMS.

Scope and limits

• This is a preview. The public contracts listed in the README (CLI JSON v1,
  diagnostic codes, Project JSON v2, Semantic metadata artifact v1, the project
  configuration and the golden fixture policy for byte-exact SQL output),
  together with pietto.sql-emission.v1, pietto.emission-contract.v1 and the
  public pietto.sql.emit_postgres_sql emitter, follow their documented
  compatibility rules; other behavior may change in later previews.
• Database execution and result APIs are not public yet; they are planned for
  the next phase. The execute-* extras install PyArrow and one route's
  pinned drivers, for private code paths only.
• Verified with CPython 3.12 and 3.13 on Linux x86-64. Other platforms and
  Python versions are not covered by this evidence.
• Not published on PyPI.

License

MIT. Third-party material in the wheel, the sdist and the source archive is
listed in THIRD_PARTY_NOTICES.md, with the original license texts in
LICENSES/.

Release artifacts

The wheel and sdist below are the exact bytes that were built once and
accepted. SHA256SUMS lists their SHA-256 digests.