Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[Feature]: expand expression evaluator filter set (upper, lower, length, split, sort, to_json)

Fechada
  • Algo errado?
#4,614 8 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
52/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
tooling

Direção de pesquisa

Start in src/specify_cli/workflows/expressions.py, reading the existing filter registration and _apply_filter() implementation around lines 20-26 and 419-484. Then inspect tests/test_workflows.py and the existing filter tests to understand input and error conventions. The work is done when the agreed filter set is registered, implemented, and covered by tests, including the unresolved length semantics and naming decisions.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

feature-assess feature-needs-clarification triage-can-wait

Problem

The workflow expression evaluator currently supports only 5 filters: default, join, map, contains, and from_json. For a system marketed as "Jinja2-like," common string and collection operations are missing, forcing workflow authors to shell out for basic transformations.

Missing filters that workflow authors frequently need:

  • String operations: upper, lower, trim (whitespace), split (string to list)
  • Collection operations: length, first, last, sort, unique
  • Serialization: to_json (the reverse of existing from_json)

Example of current limitation:

# Cannot do this today — no `length` filter:
- id: check
  type: shell
  config:
    command: "echo 'Found {{ items | length }} files'"

# Cannot do this today — no `split` filter:
- id: list
  type: shell
  config:
    command: "echo '{{ file_list | split(\",\") | length }} files found'"

Proposed Solution

Add a batch of new filters to the expression evaluator, following the existing registration pattern.

String Filters
Filter Input Output Example
upper "hello" "HELLO" {{ name | upper }}
lower "HELLO" "hello" {{ name | lower }}
trim " hi " "hi" {{ name | trim }}
split "a,b,c" ["a","b","c"] {{ csv | split(",") }}
Collection Filters
Filter Input Output Example
length ["a","b"] 2 {{ items | length }}
first ["a","b","c"] "a" {{ items | first }}
last ["a","b","c"] "c" {{ items | last }}
sort [3,1,2] [1,2,3] {{ items | sort }}
unique ["a","a","b"] ["a","b"] {{ items | unique }}
Serialization Filter
Filter Input Output Example
to_json {"key":"val"} "{\"key\":\"val\"}" {{ data | to_json }}

Design Notes

  • Follows existing pattern: Each filter is a standalone function registered in _REGISTERED_FILTERS and dispatched in _apply_filter() (expressions.py lines 20-26, 419-484)
  • Safe by design: All operations are pure transformations — no arbitrary code execution, no side effects, consistent with the sandboxed evaluator model
  • length enables conditionals: Unlocks {% if items | length > 0 %} patterns that currently require shell workarounds
  • split bridges shell output: Shell steps return newline/comma-separated strings; split converts them to lists for downstream processing
  • to_json completes the round-trip: from_json exists; to_json is its natural pair for passing structured data back to shell commands

Affected Files

  • src/specify_cli/workflows/expressions.py — filter registration and implementation (lines 20-26, 419-484)
  • tests/test_workflows.py — unit tests for each new filter

Questions

  1. Are there additional filters you would want in this batch, or should we start with a smaller set?
  2. Should length work on both lists and strings (Jinja2 behavior), or only collections?
  3. Any naming preferences (e.g., len vs length, flatten vs unique)?

Happy to implement if this aligns with your plans for the expression engine.

Linguagem predominante
Python
Estrelas
140k
Forks
12.6k
Merge médio
1d 5h
PRs com merge (30d)
189

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de github/spec-kit

Todas as issues de github/spec-kit

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.