rust-py-cache 0.2.2__tar.gz → 0.3.0__tar.gz

rust_py_cache-0.3.0/.github/workflows/release.yml

@@ -0,0 +1,389 @@
+# ─────────────────────────────────────────────────────────────────────────────
+# release.yml canônico dos `rust_py_*`  —  P3-1
+#
+# Um arquivo só por projeto: lint, teste, build da matriz, ensaio no TestPyPI e
+# publicação. Substitui o par `ci.yml` + `release.yml` que `cache` e
+# `rate_limit` mantinham, e que tinha um problema silencioso — ver "Por que um
+# workflow só", abaixo.
+#
+# Gerado a partir de `rust_py_template/.github/workflows/release.yml` em
+# 12/08/2026 — o `cache` é o primeiro projeto a adotar o formato unificado.
+# Correção feita aqui deve voltar para o template, senão a divergência
+# recomeça pelo mesmo caminho de sempre.
+#
+# ⚠️ NÃO RENOMEAR ESTE ARQUIVO. O trusted publisher cadastrado no PyPI amarra
+# `release.yml`; renomear quebra a publicação até o cadastro ser refeito.
+#
+# Substituiu o par `ci.yml` + `release.yml` que o `cache` mantinha.
+#
+# ── POR QUE UM WORKFLOW SÓ ───────────────────────────────────────────────────
+# `cache` e `rate_limit` tinham dois arquivos, e a divisão escondia uma
+# inversão: o `ci.yml` deles rodava a suíte RICA (multi-OS, Python 3.10–3.13)
+# em push/PR sem barrar nada, enquanto o `release.yml` barrava a publicação com
+# uma suíte MAGRA (ubuntu, 3.12). Ou seja, o portão do PyPI era o teste mais
+# fraco dos dois. `needs` não atravessa workflow — é a lição do P1-1, aqui numa
+# segunda forma.
+#
+# Este arquivo resolve juntando: a suíte rica é a que barra o release.
+# ─────────────────────────────────────────────────────────────────────────────
+
+name: CI / Release
+
+on:
+  push:
+    branches: [main]
+    tags: ["v*"]            # `v*`, nunca `*` — ver nota no job `release`
+  pull_request:
+  workflow_dispatch: {}
+
+permissions:
+  contents: read
+
+env:
+  PACKAGE_NAME: rust-py-cache
+  # 2 manylinux + 2 musllinux + 1 windows + 2 macos. O `monitor` soma 4 do
+  # PyPy (11); o `scheduler`, com a matriz longa, chega a 15.
+  MIN_WHEELS: "7"
+
+jobs:
+  # ── PORTÃO 1: lint ─────────────────────────────────────────────────────────
+  # Barra o release junto com o `test`. Nos repositórios de workflow único, um
+  # `lint` vermelho ao lado de uma publicação bem-sucedida seria ilegível — a
+  # leitura tem que ser inequívoca: vermelho significa que não publicou.
+  lint:
+    name: fmt + clippy
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      # Versão fixa, não "stable". Com `-D warnings`, um clippy mais novo no
+      # runner reprova código que ninguém tocou, e a CI fica vermelha por conta
+      # do calendário. Subir este número vira uma mudança deliberada.
+      - uses: dtolnay/rust-toolchain@1.88.0
+        with:
+          components: rustfmt, clippy
+      - uses: Swatinem/rust-cache@v2
+      - name: cargo fmt
+        run: cargo fmt --all -- --check
+      # clippy só checa tipos, não linka, então --all-features é seguro aqui —
+      # diferente do `cargo test`, que precisa de --no-default-features.
+      - name: cargo clippy
+        run: cargo clippy --all-targets --all-features -- -D warnings
+
+  # ── PORTÃO 2: teste ────────────────────────────────────────────────────────
+  # Nada é construído e nada chega ao PyPI antes disto passar. Publicação no
+  # PyPI é irreversível: um wheel ruim não pode ser substituído, só yankado.
+  test:
+    name: Test (${{ matrix.os }}, Python ${{ matrix.python-version }})
+    runs-on: ${{ matrix.os }}
+    strategy:
+      fail-fast: false
+      # A matriz veio do `ci.yml` do `cache` e do `CI.yml` do `rate_limit`, que
+      # tinham a cobertura mais larga dos cinco — e que, por viverem em
+      # workflow separado, não barravam nada. Agora barram.
+      #
+      # O eixo de SO é o do `cache`, reduzido: ele rodava macOS em três versões
+      # de Python, o que dobrava a matriz para provar a mesma coisa. Uma versão
+      # em macOS basta para pegar o que ubuntu não pega (link da extensão,
+      # caminho de arquivo, comportamento de thread). O eixo de Python inteiro
+      # fica no ubuntu, que é onde ele importa.
+      matrix:
+        os: [ubuntu-latest]
+        python-version: ["3.10", "3.11", "3.12", "3.13"]
+        include:
+          - os: macos-latest
+            python-version: "3.12"
+    steps:
+      - uses: actions/checkout@v4
+      - uses: dtolnay/rust-toolchain@stable
+      - uses: actions/setup-python@v5
+        with:
+          python-version: ${{ matrix.python-version }}
+      - uses: Swatinem/rust-cache@v2
+
+      # --no-default-features desliga `extension-module`, que manda o linker
+      # deixar os símbolos da libpython indefinidos. Correto para a wheel, mas
+      # produz um binário de teste que não linka no Linux.
+      #
+      # ⚠️ O `rate_limit` é o único sem seção `[features]` no Cargo.toml — lá
+      # o `extension-module` vem só de `[tool.maturin].features`, e a flag é
+      # inócua. Alinhar o Cargo.toml dele é item pendente.
+      - name: Rust unit tests
+        # Uma vez por SO basta: o core não muda com a versão do Python.
+        if: matrix.python-version == '3.12'
+        env:
+          PYO3_PYTHON: python
+        run: cargo test --no-default-features --lib
+
+      # `pip install` aciona o backend maturin, compila a extensão e a instala
+      # no Python do runner. Ao contrário de `maturin develop`, não exige
+      # virtualenv — armadilha que custou um release do `monitor` (P1-9).
+      # Instalar não-editável faz os testes exercitarem o artefato que embarca.
+      - name: Build, install the extension and run the Python tests
+        run: |
+          python -m pip install --upgrade pip
+          python -m pip install ".[dev]"
+          python -m pytest -q
+
+  # ── BUILD ──────────────────────────────────────────────────────────────────
+  # Guardados por tag OU disparo manual: um push comum não precisa pagar a
+  # matriz inteira, mas o ensaio no TestPyPI precisa dos artefatos.
+  #
+  # `fail-fast: false` em todas as matrizes: sem isso, um alvo que cai CANCELA
+  # os irmãos. Em 12/08/2026 o build x86 do `scheduler` quebrou num 403 do
+  # vault.centos.org e levou junto o diagnóstico de armv7/s390x/ppc64le.
+  #
+  # Nenhum job de build passa `--find-interpreter`: com `abi3-py310` ele não
+  # produz nada a mais. Verificado — o `audit` publicava 7 wheels, todos abi3,
+  # com a flag ligada. É flag morto e confunde quem lê.
+  linux:
+    runs-on: ubuntu-latest
+    if: startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch'
+    needs: [lint, test]
+    strategy:
+      fail-fast: false
+      matrix:
+        target: [x86_64, aarch64]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: PyO3/maturin-action@v1
+        with:
+          target: ${{ matrix.target }}
+          args: --release --out dist
+          # `auto` constrói dentro do container manylinux, para o wheel
+          # declarar um piso de glibc portável em vez do glibc do runner.
+          manylinux: auto
+      - uses: actions/upload-artifact@v4
+        with:
+          name: wheels-linux-${{ matrix.target }}
+          path: dist
+
+  musllinux:
+    runs-on: ubuntu-latest
+    if: startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch'
+    needs: [lint, test]
+    strategy:
+      fail-fast: false
+      matrix:
+        target: [x86_64, aarch64]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: PyO3/maturin-action@v1
+        with:
+          target: ${{ matrix.target }}
+          args: --release --out dist
+          manylinux: musllinux_1_2
+      - uses: actions/upload-artifact@v4
+        with:
+          name: wheels-musllinux-${{ matrix.target }}
+          path: dist
+
+  windows:
+    runs-on: windows-latest
+    if: startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch'
+    needs: [lint, test]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          architecture: x64
+      - uses: PyO3/maturin-action@v1
+        with:
+          target: x64
+          args: --release --out dist
+      - uses: actions/upload-artifact@v4
+        with:
+          name: wheels-windows-x64
+          path: dist
+
+  macos:
+    runs-on: macos-latest
+    if: startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch'
+    needs: [lint, test]
+    strategy:
+      fail-fast: false
+      matrix:
+        target: [x86_64, aarch64]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: PyO3/maturin-action@v1
+        with:
+          target: ${{ matrix.target }}
+          args: --release --out dist
+      - uses: actions/upload-artifact@v4
+        with:
+          name: wheels-macos-${{ matrix.target }}
+          path: dist
+
+  sdist:
+    runs-on: ubuntu-latest
+    if: startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch'
+    needs: [lint, test]
+    steps:
+      - uses: actions/checkout@v4
+      - uses: PyO3/maturin-action@v1
+        with:
+          command: sdist
+          args: --out dist
+      - uses: actions/upload-artifact@v4
+        with:
+          name: wheels-sdist
+          path: dist
+
+  # ── ENSAIO ─────────────────────────────────────────────────────────────────
+  # Valida a troca OIDC inteira sem tocar no índice de produção. É onde um
+  # publisher mal cadastrado deve ser descoberto — no PyPI, um nome de arquivo
+  # publicado nunca pode ser reusado.
+  #
+  # ⚠️ Precisa do seu próprio publisher, cadastrado no TestPyPI (conta separada
+  # do PyPI), com environment `testpypi`.
+  #
+  # Sem verificação pós-upload de propósito: o que se valida aqui é a troca de
+  # token, e o TestPyPI expira distribuições — reprovar por um arquivo que o
+  # índice de teste descartou seria alarme falso.
+  publish-testpypi:
+    name: Publish to TestPyPI (ensaio)
+    runs-on: ubuntu-latest
+    if: github.event_name == 'workflow_dispatch'
+    needs: [lint, test, linux, musllinux, windows, macos, sdist]
+    environment: testpypi
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          pattern: wheels-*
+          path: dist
+          merge-multiple: true
+      - uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          repository-url: https://test.pypi.org/legacy/
+          packages-dir: dist
+          skip-existing: true
+
+  # ── PUBLICAÇÃO ─────────────────────────────────────────────────────────────
+  release:
+    name: Publish to PyPI
+    runs-on: ubuntu-latest
+    # SÓ TAG. Sem a cláusula de `workflow_dispatch` que os jobs de build têm —
+    # a assimetria é a proteção: disparo manual vai ao TestPyPI, só a tag chega
+    # ao índice de verdade.
+    #
+    # ⚠️ Isto depende do filtro `tags: ["v*"]` lá em cima. O `scheduler` usava
+    # `'*'`, e como esta guarda só checa `refs/tags/`, QUALQUER tag empurrada
+    # teria publicado. Corrigido em 12/08/2026.
+    if: startsWith(github.ref, 'refs/tags/')
+    needs: [lint, test, linux, musllinux, windows, macos, sdist]
+
+    # Trusted publishing (OIDC): sem `secrets.PYPI_API_TOKEN`. O GitHub emite
+    # um JWT curto afirmando repositório, workflow e ref, e o PyPI o troca por
+    # um token de upload de poucos minutos, restrito a este projeto.
+    #
+    # ⚠️ Os três valores precisam bater EXATAMENTE com o publisher cadastrado
+    # em PyPI → Manage → Publishing:
+    #   owner/repo .... <owner>/<repo>
+    #   workflow ...... release.yml   (o NOME DO ARQUIVO, não o `name:` acima)
+    #   environment ... pypi
+    # Errar qualquer um dá `invalid-publisher`, que é falha segura: acontece na
+    # troca do token, depois de construir tudo e antes de qualquer arquivo sair
+    # do runner.
+    environment: pypi
+    permissions:
+      id-token: write
+
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          pattern: wheels-*
+          path: dist
+          merge-multiple: true
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+      - name: Install the verification dependency
+        run: python -m pip install --upgrade requests
+
+      # Conferência antes de qualquer coisa sair do runner: publicar um
+      # conjunto incompleto é pior que não publicar, porque o PyPI nunca deixa
+      # reusar um nome de arquivo — uma versão meio-publicada só pode ser
+      # completada, nunca substituída. Aconteceu de verdade: `monitor` 0.4.0
+      # ficou com 37 de 45 arquivos e sem sdist (P1-9).
+      - name: Verify the artifact set is complete
+        run: |
+          set -euo pipefail
+          ls -la dist/
+          test -n "$(find dist -name '*.tar.gz' -print -quit)" \
+            || { echo "::error::sdist ausente — abortando antes de publicar"; exit 1; }
+          wheels=$(find dist -name '*.whl' | wc -l)
+          echo "wheels: $wheels (mínimo ${MIN_WHEELS})"
+          test "$wheels" -ge "${MIN_WHEELS}" \
+            || { echo "::error::só $wheels wheels; esperado >= ${MIN_WHEELS}"; exit 1; }
+
+      # O PyPI devolve 500 transitório com frequência suficiente para importar,
+      # e o upload é arquivo por arquivo: uma falha no meio deixa a versão
+      # publicada pela metade. `skip-existing` torna a segunda tentativa segura
+      # — sem ele, ela morre nos arquivos que já subiram.
+      #
+      # Dois passos explícitos em vez de um wrapper de retry porque o trusted
+      # publishing exige a action oficial, que não dá para acionar por linha de
+      # comando de dentro do `nick-fields/retry`.
+      #
+      # ⚠️ Se a primeira tentativa falhar por `invalid-publisher`, a segunda vai
+      # falhar igual — é erro de configuração, não transitório. Custa 45s de
+      # espera inútil; melhoria conhecida e ainda não feita.
+      - name: Publish to PyPI (attempt 1)
+        id: publish1
+        continue-on-error: true
+        uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          packages-dir: dist
+          skip-existing: true
+
+      - name: Wait before retrying
+        if: steps.publish1.outcome == 'failure'
+        run: sleep 45
+
+      - name: Publish to PyPI (attempt 2)
+        if: steps.publish1.outcome == 'failure'
+        uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          packages-dir: dist
+          skip-existing: true
+
+      # Prova que a release está completa, em vez de confiar num código de
+      # saída que uma publicação parcial também produz.
+      - name: Verify every file reached PyPI
+        run: |
+          set -euo pipefail
+          python - <<'PY'
+          import os, sys, glob, time, requests
+          package = os.environ["PACKAGE_NAME"]
+          version = os.environ["GITHUB_REF_NAME"].lstrip("v")
+          # Só .whl e .tar.gz: os únicos tipos que o PyPI hospeda. O
+          # `pypa/gh-action-pypi-publish` deixa um .publish.attestation por
+          # distribuição em dist/ DEPOIS de publicar (atestados PEP 740, que
+          # sobem junto do arquivo e não como arquivo próprio). Um glob amplo
+          # os conta como "faltando" e reprova uma release que deu certo — foi
+          # o alarme falso da rate_limit 0.2.1 (P1-9).
+          local = {
+              os.path.basename(p)
+              for pattern in ("dist/*.whl", "dist/*.tar.gz")
+              for p in glob.glob(pattern)
+          }
+          url = f"https://pypi.org/pypi/{package}/{version}/json"
+          for attempt in range(6):          # a API JSON do PyPI é cacheada
+              response = requests.get(url, timeout=30)
+              if response.status_code == 200:
+                  remote = {f["filename"] for f in response.json()["urls"]}
+                  missing = local - remote
+                  if not missing:
+                      print(f"OK: {len(remote)} arquivos publicados na {version}")
+                      sys.exit(0)
+              else:
+                  missing = local
+              print(f"tentativa {attempt + 1}: faltam {len(missing)}")
+              time.sleep(20)
+          print("::error::faltaram arquivos no PyPI:")
+          for name in sorted(missing):
+              print(f"  - {name}")
+          sys.exit(1)
+          PY

{rust_py_cache-0.2.2 → rust_py_cache-0.3.0}/.gitignore

@@ -5,3 +5,6 @@ __pycache__/
 dist/
 *.egg-info/
 .pytest_cache/
+
+# macOS
+.DS_Store

rust_py_cache-0.3.0/CHANGELOG.md

@@ -0,0 +1,180 @@
+# Changelog
+
+Todas as mudanças relevantes deste projeto são registradas aqui.
+
+O formato segue [Keep a Changelog](https://keepachangelog.com/pt-BR/1.1.0/),
+e o versionamento segue [SemVer](https://semver.org/lang/pt-BR/).
+
+## [0.3.0] — não publicada
+
+Evicção LRU com custo amortizado O(1) (**P2-2**). Inclui também tudo o que
+estava na 0.2.4, que nunca chegou a ser publicada.
+
+### Alterado
+
+- **A evicção LRU passou a remover um lote, não uma entrada.** Até a 0.2.x,
+  achar a entrada menos recentemente usada varria o `DashMap` inteiro — e isso
+  acontecia a **cada** `set` de chave nova com o cache cheio, que é o regime
+  normal de um cache cheio sob escrita. Agora cada varredura remove
+  `max_size / 32` entradas (no mínimo 1), e a próxima só vem depois de outras
+  ~n/32 inserções. Medido com `max_size=100_000`: **~620 µs → ~1,6 µs** por
+  `set` com o cache cheio (com 10 000: ~70 µs → ~1,5 µs). O custo deixou de
+  crescer com o tamanho do cache.
+- A seleção acha o corte com `select_nth_unstable` sobre os carimbos de acesso
+  (sem clonar chaves nem ordenar) e remove com `remove_if`, que recheca o
+  carimbo: uma chave lida por outra thread no meio da varredura fica.
+- Um `Mutex` cobre **só** o caminho de evicção, para várias threads que acham o
+  cache cheio ao mesmo tempo não varrerem em paralelo. `get`/`set` comuns não o
+  tocam.
+
+### Compatibilidade
+
+- Nenhuma API mudou. O que muda de observável, e por isso o minor sobe: logo
+  depois de uma evicção o cache fica ~3% abaixo de `max_size` (antes ficava em
+  `max_size - 1`), e `stats()["evicted"]` cresce em lotes. Com `max_size < 64`
+  o lote é de 1 entrada e o comportamento é idêntico ao anterior.
+- Amostragem estilo Redis, que o backlog sugeria, foi descartada: exigiria
+  acesso aleatório às entradas, que o `DashMap` só expõe pela `raw-api` (tabela
+  interna do hashbrown, iteração `unsafe`).
+
+## [0.2.4] — não publicada
+
+Adoção do `release.yml` unificado do template (**P3-1**). Nada muda no
+comportamento da biblioteca — mas muda, e bastante, o que precisa passar antes
+de uma versão chegar ao PyPI.
+
+### Corrigido
+
+- **O release era barrado pela suíte mais fraca das duas.** O projeto tinha
+  dois workflows, e a divisão escondia uma inversão:
+
+  | | rodava | barrava o release? |
+  | --- | --- | --- |
+  | `ci.yml` | ubuntu + macOS × Python 3.10/3.12/3.13 | **não** |
+  | `release.yml` | ubuntu × Python 3.12 | sim |
+
+  Ou seja, a suíte boa não protegia nada e o portão do PyPI era a magra.
+  `needs` não atravessa workflow — a mesma lição do P1-1, numa segunda forma.
+  Os dois arquivos ainda mantinham o job `lint` duplicado.
+
+  Agora é um workflow só, e quem barra a publicação é
+  **ubuntu × Python 3.10/3.11/3.12/3.13 + macOS × 3.12**.
+
+  ⚠️ O eixo de macOS foi reduzido de três versões de Python para uma. Rodar as
+  três dobrava a matriz para provar a mesma coisa; uma basta para pegar o que
+  o ubuntu não pega (link da extensão, caminhos, threads).
+
+### Adicionado
+
+- **Ensaio no TestPyPI** (`publish-testpypi`, por `workflow_dispatch`), que o
+  projeto não tinha. Valida a troca de token OIDC sem tocar no índice de
+  produção. ⚠️ Exige um publisher próprio cadastrado no TestPyPI.
+- **`fail-fast: false`** nas matrizes: um alvo que cai deixava de cancelar os
+  irmãos e apagar o diagnóstico deles.
+
+### Removido
+
+- **`.github/workflows/ci.yml`**, fundido no `release.yml`.
+
+## [0.2.3] - 2026-08-12
+
+Versão de empacotamento e qualidade: nada muda no comportamento da biblioteca.
+
+### Adicionado
+
+- **`LICENSE`** (MIT). O projeto declarava MIT no `pyproject.toml` desde sempre,
+  mas o texto da licença não existia no repositório nem na wheel (**P1-4**).
+- **`clippy.toml` e `Makefile`** compartilhados com os outros quatro `rust_py_*`,
+  e um job `lint` (`cargo fmt --check` + `cargo clippy -D warnings`) no `ci.yml`
+  e no `release.yml` — este barrando a publicação, como o `test` já barrava
+  (**P1-6**). O `cargo clippy` já estava limpo aqui; foi o único dos cinco.
+
+### Corrigido
+
+- **Metadado de licença ausente no PyPI.** O `pyproject.toml` usava
+  `license = { text = "MIT" }`, forma legada que o Metadata 2.4 depreca. Passou
+  para a do PEP 639 (`license = "MIT"` + `license-files = ["LICENSE"]`), e o
+  classifier `License :: OSI Approved` saiu — ele é mutuamente exclusivo com
+  `License-Expression`. A 0.2.2 no PyPI mostra `license: MIT` no campo legado e
+  `license_expression: null`; a partir daqui é o contrário, que é o correto.
+
+- **Piso da maturin subiu para 1.14** no `[build-system]`. Era `>=1.7`, e
+  versões anteriores não emitem `License-Expression` — foi essa, e não a forma
+  no `pyproject`, a causa raiz do metadado faltando.
+
+### Declarado como Cargo
+
+- `Cargo.toml` não tinha campo `license` nenhum. Agora tem `license = "MIT"`,
+  como os outros quatro.
+
+## [0.2.2] - 2026-08-11
+
+Release de infraestrutura: nada muda no comportamento da biblioteca, mas muda
+quem consegue instalá-la sem compilar.
+
+### Corrigido
+
+- **A publicação não roda mais sem teste.** O `ci.yml` roda em push/PR, mas é
+  um workflow **separado**: um push de tag ia direto para build e publicação
+  sem depender dele. O `release.yml` agora tem o seu próprio job `test` e todos
+  os demais declaram `needs: test`. O job `publish` também ganhou
+  `if: startsWith(github.ref, 'refs/tags/')` — sem essa guarda, um
+  `workflow_dispatch` a partir de um branch publicaria no PyPI.
+  (BACKLOG2 P1-1)
+- **Cobertura de plataformas.** A 0.2.1 publicou 3 wheels — uma por runner
+  (ubuntu, macos, windows) — e a de Linux herdava a glibc da máquina de build
+  em vez de passar pelo container manylinux. Caíam no sdist, ou seja,
+  precisavam de toolchain Rust: Linux aarch64, Alpine/musl e Mac Intel. Agora
+  são 7 wheels (2 manylinux, 2 musllinux, 1 Windows, 2 macOS) mais o sdist.
+- **O upload aguenta o 500 do PyPI.** O upload é arquivo por arquivo e sem
+  transação — uma falha no meio deixa a versão publicada pela metade, e o PyPI
+  nunca permite reusar um nome de arquivo. Agora há `skip-existing` (que é o
+  que torna a segunda tentativa segura), uma segunda tentativa explícita,
+  conferência do conjunto de artefatos **antes** de publicar e validação contra
+  a API do PyPI **depois**. (BACKLOG2 P1-9)
+
+### Alterado
+
+- `crate-type` ganhou `rlib` além de `cdylib`, e `extension-module` virou
+  feature opcional ligada por padrão. Assim
+  `cargo test --no-default-features --lib` produz um binário de teste que linka
+  no Linux, em vez de depender da tolerância do linker do macOS. É o mesmo
+  arranjo dos outros quatro projetos. (BACKLOG2 P1-8)
+- O `ci.yml` deixou de criar um virtualenv à mão para rodar `maturin develop`;
+  agora usa `pip install ".[dev]"`, que aciona o mesmo backend maturin sem
+  exigir virtualenv.
+
+### Adicionado
+
+- Extra `[project.optional-dependencies] dev`. Este era o único dos cinco
+  projetos sem um. (BACKLOG2 P2-9)
+
+## [0.2.1] - 2026-08-11
+
+### Corrigido
+
+- `@cache.cached` sobre função `async def` guardava no cache o objeto coroutine
+  em vez do resultado do `await`, quebrando o decorator já na primeira chamada
+  com `TypeError: cannot pickle 'coroutine' object`. O decorator agora detecta
+  `inspect.iscoroutinefunction` e gera um wrapper `async` que faz o `await`
+  antes do `set`. (BACKLOG2 P0-2)
+
+## [0.2.0]
+
+### Adicionado
+
+- Expiração em background via `Sweeper` (thread dedicada com `Weak<T>`,
+  encerramento limpo no `Drop`).
+- Evicção por `max_size` com política LRU.
+- Exemplos para FastAPI e Django.
+
+## [0.1.x]
+
+### Adicionado
+
+- `Cache` com `set` / `get(default=...)` / `delete` / `exists` / `keys` /
+  `len` / `clear` / `cleanup_expired` / `stats`.
+- TTL por entrada com expiração preguiçosa.
+- `stats()` cumulativo baseado em `AtomicU64`.
+- Decorator de memoização `@cache.cached(ttl=..., key=...)`.
+- Core em Rust sobre `DashMap`, valores serializados com `pickle`.

{rust_py_cache-0.2.2 → rust_py_cache-0.3.0}/Cargo.lock

@@ -202,7 +202,7 @@ dependencies = [
 
 [[package]]
 name = "rust_py_cache"
-version = "0.2.2"
+version = "0.3.0"
 dependencies = [
  "dashmap",
  "pyo3",

{rust_py_cache-0.2.2 → rust_py_cache-0.3.0}/Cargo.toml

@@ -1,7 +1,8 @@
 [package]
 name = "rust_py_cache"
-version = "0.2.2"
+version = "0.3.0"
 edition = "2021"
+license = "MIT"
 readme = "README.md"
 
 # Biblioteca de extensão para Python:

rust_py_cache-0.3.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Roberto Lima
+
+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.

rust_py_cache-0.3.0/Makefile

@@ -0,0 +1,68 @@
+# Makefile compartilhado dos `rust_py_*`.
+#
+# Existe para que a CI e a pessoa rodem exatamente o mesmo comando. Quando o
+# lint da CI diverge do lint local, quem perde é sempre quem abriu o PR.
+#
+# A toolchain NÃO é fixada por `rust-toolchain.toml` de propósito: esse arquivo
+# vale para toda invocação do cargo, inclusive a dos containers manylinux do
+# release, e um download de toolchain no meio de uma publicação no PyPI é risco
+# sem contrapartida. A fixação vive no job de lint da CI, que é onde
+# `-D warnings` realmente morde. Localmente, use uma stable recente.
+
+PYTHON ?= python3
+
+# Fixa qual Python o pyo3 usa na compilação. Sem isto ele pega o primeiro do
+# PATH, que pode não ser o mesmo do `make dev` — e aí o binário de teste linka
+# contra uma libpython e o pytest roda contra outra.
+export PYO3_PYTHON ?= $(PYTHON)
+
+# No macOS o binário de `cargo test` carrega a libpython em runtime, e o dyld
+# não a encontra sozinho: o erro é `Library not loaded: @rpath/libpython3.X.dylib`,
+# em SIGABRT, depois de compilar com sucesso — parece falha de teste e não é.
+# Os caminhos padrão entram junto porque definir DYLD_FALLBACK_LIBRARY_PATH
+# *substitui* a lista default do dyld em vez de acrescentar a ela (senão o
+# erro seguinte é libiconv.2.dylib).
+PY_LIBDIR := $(shell $(PYTHON) -c 'import sysconfig; print(sysconfig.get_config_var("LIBDIR") or "")' 2>/dev/null)
+export DYLD_FALLBACK_LIBRARY_PATH := $(PY_LIBDIR):/opt/homebrew/lib:/usr/local/lib:/usr/lib
+
+.PHONY: help dev test lint fmt clippy test-rust test-python clean
+
+help:
+	@echo "make dev          instala o pacote em modo editável com os extras de dev"
+	@echo "make test         cargo test + pytest"
+	@echo "make lint         cargo fmt --check + cargo clippy -D warnings"
+	@echo "make fmt          aplica a formatação (escreve nos arquivos)"
+
+# `pip install` aciona o backend maturin, compila a extensão e instala.
+# Ao contrário de `maturin develop`, não exige um virtualenv ativo — que é
+# exatamente a armadilha que custou um release do monitor (ver P1-9).
+dev:
+	$(PYTHON) -m pip install --upgrade pip
+	$(PYTHON) -m pip install -e ".[dev]"
+
+test: test-rust test-python
+
+# --no-default-features desliga `extension-module`, que impede o binário de
+# teste de linkar contra a libpython no Linux. --lib porque os testes de
+# integração precisam do módulo nativo, e esses ficam do lado Python.
+test-rust:
+	cargo test --no-default-features --lib
+
+test-python:
+	pytest -q
+
+lint: fmt-check clippy
+
+.PHONY: fmt-check
+fmt-check:
+	cargo fmt --all -- --check
+
+clippy:
+	cargo clippy --all-targets --all-features -- -D warnings
+
+fmt:
+	cargo fmt --all
+
+clean:
+	cargo clean
+	rm -rf dist build *.egg-info .pytest_cache