Regras do Python
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Regras
py_binary
Ver origem da regraopen_in_new
py_binary(name, deps, srcs, data, args, compatible_with, deprecation, distribs, env, exec_compatible_with, exec_properties, features, imports, legacy_create_init, licenses, main, output_licenses, precompile, precompile_invalidation_mode, precompile_optimize_level, precompile_source_retention, pyc_collection, python_version, restricted_to, srcs_version, stamp, tags, target_compatible_with, testonly, toolchains, visibility)
Argumentos
| Atributos |
name |
Nome: obrigatório
Um nome exclusivo para essa segmentação.
|
deps
|
Lista de rótulos. O padrão é [].
Lista de bibliotecas adicionais a serem vinculadas ao destino.
Consulte os comentários sobre o atributo [`deps` normalmente definido por
regras](https://bazel.build/reference/be/common-definitions#typical-attributes).
Normalmente, são regras "py_library".
Os destinos que fornecem apenas arquivos de dados usados no tempo de execução pertencem ao atributo "data".
|
srcs
|
Lista de marcadores; obrigatório
A lista de arquivos de origem Python processados para criar o destino. Isso inclui todo o código registrado e pode incluir arquivos de origem gerados. Os arquivos
`.py` pertencem a `srcs`, e os destinos de biblioteca pertencem a `deps`. Outros arquivos
binários que podem ser necessários no tempo de execução pertencem a `data`.
|
data
|
Lista de rótulos. O padrão é [].
A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte os comentários sobre o atributo [`data` normalmente definido por regras](https://bazel.build/reference/be/common-definitions#typical-attributes).
Não há um `py_embed_data` como `cc_embed_data` e `go_embed_data`, porque o Python tem um conceito de recursos de tempo de execução.
|
imports
|
Lista de strings. O padrão é [].
Lista de diretórios de importação a serem adicionados ao PYTHONPATH.
Sujeito à substituição "Criar variável". Esses diretórios de importação serão adicionados
para essa regra e todas as regras que dependem dela (observação: não as regras de que essa regra
depende). Cada diretório será adicionado a "PYTHONPATH" por regras "py_binary"
que dependem dessa regra. As strings são relativas a repo-runfiles-root.
Caminhos absolutos (que começam com "/") e caminhos que referenciam um caminho
acima da raiz de execução não são permitidos e resultam em um erro.
|
legacy_create_init
|
Número inteiro. O padrão é -1.
Se é preciso criar implicitamente arquivos `__init__.py` vazios na árvore de arquivos de execução.
Eles são criados em todos os diretórios que contêm código-fonte Python ou bibliotecas
compartilhadas, e em todos os diretórios principais desses diretórios, exceto o diretório
raiz do repositório. O padrão, `-1` (automático), significa "true", a menos que
`--incompatible_default_to_explicit_init_py` seja usado. Se for "false", o usuário será responsável por criar arquivos `__init__.py` (possivelmente vazios) e adicioná-los aos `srcs` dos destinos do Python, conforme necessário.
|
main
|
Rótulo; o padrão é None
Opcional. É o nome do arquivo de origem que é o principal ponto de entrada do
aplicativo. Esse arquivo também precisa ser listado em "srcs". Se não for especificado, o "name", com ".py" anexado, será usado. Se "name" não corresponder a nenhum nome de arquivo em "srcs", "main" precisará ser especificado.
|
precompile
|
String; o padrão é "inherit"
Se os arquivos de origem py **para essa meta** devem ser pré-compilados.
Valores:
* `inherit`: permite que o binário downstream decida se os arquivos pré-compilados serão usados.
* `enabled`: compila arquivos de origem Python no momento da build.
* `disabled`: não compila arquivos de origem Python no momento da build.
:::{seealso}
* A flag {flag}`--precompile`, que pode substituir esse atributo em alguns casos
e afetará todas as metas ao criar.
* O atributo {obj}`pyc_collection` para ativar a pré-compilação de forma transitiva em
cada destino.
* Os documentos de [pré-compilação](precompiling) para um guia sobre como usar a pré-compilação.
:::
|
precompile_invalidation_mode
|
String; o padrão é "auto"
Como os arquivos pré-compilados devem ser verificados para garantir que estejam atualizados com os arquivos de origem associados. Os valores possíveis são:
* `auto`: o valor efetivo será determinado automaticamente por outras configurações de build.
* `checked_hash`: use o arquivo pyc se o hash do arquivo de origem corresponder ao hash registrado no arquivo pyc. Isso é mais útil ao trabalhar com código que
você pode modificar.
* `unchecked_hash`: sempre use o arquivo pyc. Não verifique o hash do pyc com o arquivo de origem. Isso é mais útil quando o código não será modificado.
Para mais informações sobre os modos de invalidação de pyc, consulte
https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode
|
precompile_optimize_level
|
Número inteiro. O padrão é 0.
O nível de otimização para arquivos pré-compilados.
Para mais informações sobre níveis de otimização, consulte os documentos do argumento "optimize" da função "compile()" em https://docs.python.org/3/library/functions.html#compile
OBSERVAÇÃO: o valor "-1" significa "interpretador atual", que será o interpretador
usado _no momento do build quando os pycs são gerados_, não o interpretador usado
no tempo de execução quando o código é executado.
|
precompile_source_retention
|
String; o padrão é "inherit"
Determina, quando um arquivo de origem é compilado, se ele é mantido
na saída resultante ou não. Os valores válidos são:
* `inherit`: herda o valor da flag {flag}`--precompile_source_retention`.
* `keep_source`: inclui a origem original do Python.
* `omit_source`: não inclui a origem py original.
|
pyc_collection
|
String; o padrão é "inherit"
Determina se os arquivos pyc das dependências precisam ser incluídos manualmente.
Os valores válidos são:
* `inherit`: herda o valor de {flag}`--precompile`.
* `include_pyc`: adiciona arquivos pyc gerados implicitamente de dependências. Ou seja,
arquivos pyc para destinos que especificam {attr}`precompile="inherit"`.
* `disabled`: não adiciona arquivos pyc gerados implicitamente. Os arquivos pyc ainda podem vir de dependências que permitem a pré-compilação no nível de destino.
|
python_version
|
String; o padrão é "PY3"
Extinto, não usado, não faz nada.
|
srcs_version
|
String; o padrão é "PY2AND3"
Extinto, não usado, não faz nada.
|
stamp
|
Número inteiro. O padrão é -1.
Determina se as informações de build serão codificadas no binário. Valores possíveis:
* `stamp = 1`: sempre marca as informações de build no binário, mesmo em
builds `--nostamp`. **Evite essa configuração**, já que ela pode encerrar o
armazenamento em cache remoto para o binário e todas as ações downstream que dependem dele.
* `stamp = 0`: sempre substitui as informações de build por valores constantes. Isso oferece um bom armazenamento em cache de resultados de build.
* `stamp = -1`: a incorporação de informações de build é controlada pela flag
`--[no]stamp`.
Os binários carimbados não são recriados, a menos que as dependências mudem.
AVISO: a inclusão de carimbos pode prejudicar a performance do build ao reduzir os hits de cache e deve ser evitada sempre que possível.
|
py_library
Ver origem da regraopen_in_new
py_library(name, deps, srcs, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, imports, licenses, precompile, precompile_invalidation_mode, precompile_optimize_level, precompile_source_retention, restricted_to, srcs_version, tags, target_compatible_with, testonly, toolchains, visibility)
Uma biblioteca de código Python que pode ser usada como dependência.
Saídas padrão:
* As fontes de entrada do Python
* Os artefatos pré-compilados das fontes.
OBSERVAÇÃO: a pré-compilação afeta quais das saídas padrão são incluídas nos
runfiles resultantes. Consulte os atributos e flags relacionados à pré-compilação para
mais informações.
::{versionchanged} 0.37.0
Os arquivos de origem não são mais adicionados diretamente aos runfiles.
:::
Argumentos
| Atributos |
name |
Nome: obrigatório
Um nome exclusivo para essa segmentação.
|
deps
|
Lista de rótulos. O padrão é [].
Lista de bibliotecas adicionais a serem vinculadas ao destino.
Consulte os comentários sobre o atributo [`deps` normalmente definido por
regras](https://bazel.build/reference/be/common-definitions#typical-attributes).
Normalmente, são regras "py_library".
Os destinos que fornecem apenas arquivos de dados usados no tempo de execução pertencem ao atributo "data".
|
srcs
|
Lista de rótulos. O padrão é [].
A lista de arquivos de origem Python processados para criar o destino. Isso inclui todo o código registrado e pode incluir arquivos de origem gerados. Os arquivos
`.py` pertencem a `srcs`, e os destinos de biblioteca pertencem a `deps`. Outros arquivos
binários que podem ser necessários no tempo de execução pertencem a `data`.
|
data
|
Lista de rótulos. O padrão é [].
A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte os comentários sobre o atributo [`data` normalmente definido por regras](https://bazel.build/reference/be/common-definitions#typical-attributes).
Não há um `py_embed_data` como `cc_embed_data` e `go_embed_data`, porque o Python tem um conceito de recursos de tempo de execução.
|
imports
|
Lista de strings. O padrão é [].
Lista de diretórios de importação a serem adicionados ao PYTHONPATH.
Sujeito à substituição "Criar variável". Esses diretórios de importação serão adicionados
para essa regra e todas as regras que dependem dela (observação: não as regras de que essa regra
depende). Cada diretório será adicionado a "PYTHONPATH" por regras "py_binary"
que dependem dessa regra. As strings são relativas a repo-runfiles-root.
Caminhos absolutos (que começam com "/") e caminhos que referenciam um caminho
acima da raiz de execução não são permitidos e resultam em um erro.
|
precompile
|
String; o padrão é "inherit"
Se os arquivos de origem py **para essa meta** devem ser pré-compilados.
Valores:
* `inherit`: permite que o binário downstream decida se os arquivos pré-compilados serão usados.
* `enabled`: compila arquivos de origem Python no momento da build.
* `disabled`: não compila arquivos de origem Python no momento da build.
:::{seealso}
* A flag {flag}`--precompile`, que pode substituir esse atributo em alguns casos
e afetará todas as metas ao criar.
* O atributo {obj}`pyc_collection` para ativar a pré-compilação de forma transitiva em
cada destino.
* Os documentos de [pré-compilação](precompiling) para um guia sobre como usar a pré-compilação.
:::
|
precompile_invalidation_mode
|
String; o padrão é "auto"
Como os arquivos pré-compilados devem ser verificados para garantir que estejam atualizados com os arquivos de origem associados. Os valores possíveis são:
* `auto`: o valor efetivo será determinado automaticamente por outras configurações de build.
* `checked_hash`: use o arquivo pyc se o hash do arquivo de origem corresponder ao hash registrado no arquivo pyc. Isso é mais útil ao trabalhar com código que
você pode modificar.
* `unchecked_hash`: sempre use o arquivo pyc. Não verifique o hash do pyc com o arquivo de origem. Isso é mais útil quando o código não será modificado.
Para mais informações sobre os modos de invalidação de pyc, consulte
https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode
|
precompile_optimize_level
|
Número inteiro. O padrão é 0.
O nível de otimização para arquivos pré-compilados.
Para mais informações sobre níveis de otimização, consulte os documentos do argumento "optimize" da função "compile()" em https://docs.python.org/3/library/functions.html#compile
OBSERVAÇÃO: o valor "-1" significa "interpretador atual", que será o interpretador
usado _no momento do build quando os pycs são gerados_, não o interpretador usado
no tempo de execução quando o código é executado.
|
precompile_source_retention
|
String; o padrão é "inherit"
Determina, quando um arquivo de origem é compilado, se ele é mantido
na saída resultante ou não. Os valores válidos são:
* `inherit`: herda o valor da flag {flag}`--precompile_source_retention`.
* `keep_source`: inclui a origem original do Python.
* `omit_source`: não inclui a origem py original.
|
srcs_version
|
String; o padrão é "PY2AND3"
Extinto, não usado, não faz nada.
|
py_test
Ver origem da regraopen_in_new
py_test(name, deps, srcs, data, args, compatible_with, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_properties, features, flaky, imports, legacy_create_init, licenses, local, main, precompile, precompile_invalidation_mode, precompile_optimize_level, precompile_source_retention, pyc_collection, python_version, restricted_to, shard_count, size, srcs_version, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility)
Argumentos
| Atributos |
name |
Nome: obrigatório
Um nome exclusivo para essa segmentação.
|
deps
|
Lista de rótulos. O padrão é [].
Lista de bibliotecas adicionais a serem vinculadas ao destino.
Consulte os comentários sobre o atributo [`deps` normalmente definido por
regras](https://bazel.build/reference/be/common-definitions#typical-attributes).
Normalmente, são regras "py_library".
Os destinos que fornecem apenas arquivos de dados usados no tempo de execução pertencem ao atributo "data".
|
srcs
|
Lista de marcadores; obrigatório
A lista de arquivos de origem Python processados para criar o destino. Isso inclui todo o código registrado e pode incluir arquivos de origem gerados. Os arquivos
`.py` pertencem a `srcs`, e os destinos de biblioteca pertencem a `deps`. Outros arquivos
binários que podem ser necessários no tempo de execução pertencem a `data`.
|
data
|
Lista de rótulos. O padrão é [].
A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte os comentários sobre o atributo [`data` normalmente definido por regras](https://bazel.build/reference/be/common-definitions#typical-attributes).
Não há um `py_embed_data` como `cc_embed_data` e `go_embed_data`, porque o Python tem um conceito de recursos de tempo de execução.
|
imports
|
Lista de strings. O padrão é [].
Lista de diretórios de importação a serem adicionados ao PYTHONPATH.
Sujeito à substituição "Criar variável". Esses diretórios de importação serão adicionados
para essa regra e todas as regras que dependem dela (observação: não as regras de que essa regra
depende). Cada diretório será adicionado a "PYTHONPATH" por regras "py_binary"
que dependem dessa regra. As strings são relativas a repo-runfiles-root.
Caminhos absolutos (que começam com "/") e caminhos que referenciam um caminho
acima da raiz de execução não são permitidos e resultam em um erro.
|
legacy_create_init
|
Número inteiro. O padrão é -1.
Se é preciso criar implicitamente arquivos `__init__.py` vazios na árvore de arquivos de execução.
Eles são criados em todos os diretórios que contêm código-fonte Python ou bibliotecas
compartilhadas, e em todos os diretórios principais desses diretórios, exceto o diretório
raiz do repositório. O padrão, `-1` (automático), significa "true", a menos que
`--incompatible_default_to_explicit_init_py` seja usado. Se for "false", o usuário será responsável por criar arquivos `__init__.py` (possivelmente vazios) e adicioná-los aos `srcs` dos destinos do Python, conforme necessário.
|
main
|
Rótulo; o padrão é None
Opcional. É o nome do arquivo de origem que é o principal ponto de entrada do
aplicativo. Esse arquivo também precisa ser listado em "srcs". Se não for especificado, o "name", com ".py" anexado, será usado. Se "name" não corresponder a nenhum nome de arquivo em "srcs", "main" precisará ser especificado.
|
precompile
|
String; o padrão é "inherit"
Se os arquivos de origem py **para essa meta** devem ser pré-compilados.
Valores:
* `inherit`: permite que o binário downstream decida se os arquivos pré-compilados serão usados.
* `enabled`: compila arquivos de origem Python no momento da build.
* `disabled`: não compila arquivos de origem Python no momento da build.
:::{seealso}
* A flag {flag}`--precompile`, que pode substituir esse atributo em alguns casos
e afetará todas as metas ao criar.
* O atributo {obj}`pyc_collection` para ativar a pré-compilação de forma transitiva em
cada destino.
* Os documentos de [pré-compilação](precompiling) para um guia sobre como usar a pré-compilação.
:::
|
precompile_invalidation_mode
|
String; o padrão é "auto"
Como os arquivos pré-compilados devem ser verificados para garantir que estejam atualizados com os arquivos de origem associados. Os valores possíveis são:
* `auto`: o valor efetivo será determinado automaticamente por outras configurações de build.
* `checked_hash`: use o arquivo pyc se o hash do arquivo de origem corresponder ao hash registrado no arquivo pyc. Isso é mais útil ao trabalhar com código que
você pode modificar.
* `unchecked_hash`: sempre use o arquivo pyc. Não verifique o hash do pyc com o arquivo de origem. Isso é mais útil quando o código não será modificado.
Para mais informações sobre os modos de invalidação de pyc, consulte
https://docs.python.org/3/library/py_compile.html#py_compile.PycInvalidationMode
|
precompile_optimize_level
|
Número inteiro. O padrão é 0.
O nível de otimização para arquivos pré-compilados.
Para mais informações sobre níveis de otimização, consulte os documentos do argumento "optimize" da função "compile()" em https://docs.python.org/3/library/functions.html#compile
OBSERVAÇÃO: o valor "-1" significa "interpretador atual", que será o interpretador
usado _no momento do build quando os pycs são gerados_, não o interpretador usado
no tempo de execução quando o código é executado.
|
precompile_source_retention
|
String; o padrão é "inherit"
Determina, quando um arquivo de origem é compilado, se ele é mantido
na saída resultante ou não. Os valores válidos são:
* `inherit`: herda o valor da flag {flag}`--precompile_source_retention`.
* `keep_source`: inclui a origem original do Python.
* `omit_source`: não inclui a origem py original.
|
pyc_collection
|
String; o padrão é "inherit"
Determina se os arquivos pyc das dependências precisam ser incluídos manualmente.
Os valores válidos são:
* `inherit`: herda o valor de {flag}`--precompile`.
* `include_pyc`: adiciona arquivos pyc gerados implicitamente de dependências. Ou seja,
arquivos pyc para destinos que especificam {attr}`precompile="inherit"`.
* `disabled`: não adiciona arquivos pyc gerados implicitamente. Os arquivos pyc ainda podem vir de dependências que permitem a pré-compilação no nível de destino.
|
python_version
|
String; o padrão é "PY3"
Extinto, não usado, não faz nada.
|
srcs_version
|
String; o padrão é "PY2AND3"
Extinto, não usado, não faz nada.
|
stamp
|
Número inteiro. O padrão é 0.
Determina se as informações de build serão codificadas no binário. Valores possíveis:
* `stamp = 1`: sempre marca as informações de build no binário, mesmo em
builds `--nostamp`. **Evite essa configuração**, já que ela pode encerrar o
armazenamento em cache remoto para o binário e todas as ações downstream que dependem dele.
* `stamp = 0`: sempre substitui as informações de build por valores constantes. Isso oferece um bom armazenamento em cache de resultados de build.
* `stamp = -1`: a incorporação de informações de build é controlada pela flag
`--[no]stamp`.
Os binários carimbados não são recriados, a menos que as dependências mudem.
AVISO: a inclusão de carimbos pode prejudicar a performance do build ao reduzir os hits de cache e deve ser evitada sempre que possível.
|
py_runtime
Ver origem da regraopen_in_new
py_runtime(name, abi_flags, bootstrap_template, compatible_with, coverage_tool, deprecation, distribs, exec_compatible_with, exec_properties, features, files, implementation_name, interpreter, interpreter_path, interpreter_version_info, pyc_tag, python_version, restricted_to, stage2_bootstrap_template, stub_shebang, tags, target_compatible_with, testonly, toolchains, visibility, zip_main_template)
Representa um ambiente de execução do Python usado para executar código Python.
Um destino `py_runtime` pode representar um *tempo de execução da plataforma* ou um *tempo de execução
no build*. Um ambiente de execução de plataforma acessa um interpretador instalado pelo sistema em um caminho conhecido, enquanto um ambiente de execução no build aponta para um destino executável que atua como o interpretador. Em ambos os casos, um "interpretador" significa qualquer binário executável ou script de wrapper capaz de executar um script Python transmitido na linha de comando, seguindo as mesmas convenções do interpretador CPython padrão.
Um ambiente de execução de plataforma é não hermético por natureza. Ele impõe à plataforma de destino a exigência de ter um intérprete localizado em um caminho específico. Um
runtime integrado pode ou não ser hermético, dependendo se ele aponta para
um interpretador verificado ou um script de wrapper que acessa o interpretador do
sistema.
Exemplo
```
load("@rules_python//python:py_runtime.bzl", "py_runtime")
py_runtime(
name = "python-2.7.12",
files = glob(["python-2.7.12/**"]),
interpreter = "python-2.7.12/bin/python",
)
py_runtime(
name = "python-3.6.0",
interpreter_path = "/opt/pyenv/versions/3.6.0/bin/python",
)
```
Argumentos
| Atributos |
name |
Nome: obrigatório
Um nome exclusivo para essa segmentação.
|
abi_flags
|
String; o padrão é ""
As flags da ABI do tempo de execução, ou seja, "sys.abiflags".
Se não for definido, será definido com base nas flags.
|
bootstrap_template
|
Rótulo; o padrão é "@rules_python//python/private:bootstrap_template"
O arquivo de modelo de script de inicialização a ser usado. Deve ter %python_binary%,
%workspace_name%, %main% e %imports%.
Esse modelo, após a expansão, se torna o arquivo executável usado para iniciar o
processo. Portanto, ele é responsável pelas ações de bootstrap iniciais, como encontrar
o interpretador Python, runfiles e construir um ambiente para executar o
aplicativo Python pretendido.
Embora esse atributo seja opcional no momento, ele será obrigatório quando as regras do Python forem movidas para fora do Bazel.
Os nomes exatos das variáveis expandidas são uma API instável e estão sujeitos a mudanças.
A API vai ficar mais estável quando as regras do Python forem removidas do próprio Bazel.
Consulte @bazel_tools//tools/python:python_bootstrap_template.txt para mais variáveis.
|
coverage_tool
|
Rótulo; o padrão é None
É uma meta usada para coletar informações de cobertura de código das metas {rule}`py_binary` e {rule}`py_test`.
Se definido, o destino precisa produzir um único arquivo ou ser um destino executável.
O caminho para o arquivo único ou o executável, se o destino for executável, determina o ponto de entrada para a ferramenta de cobertura do Python. O destino e os
arquivos de execução serão adicionados aos arquivos de execução quando a cobertura for ativada.
O ponto de entrada da ferramenta precisa ser carregável por um interpretador Python (por exemplo, um
arquivo `.py` ou `.pyc`). Ele precisa aceitar os argumentos da linha de comando
de [`coverage.py`](https://coverage.readthedocs.io), incluindo pelo menos
os subcomandos "run" e "lcov".
|
files
|
Lista de rótulos. O padrão é [].
Para um ambiente de execução no build, esse é o conjunto de arquivos que o compõem.
Esses arquivos serão adicionados aos runfiles de binários Python que usam esse
tempo de execução. Para um tempo de execução da plataforma, esse atributo não pode ser definido.
|
implementation_name
|
String; o padrão é "cpython"
O nome da implementação do Python (`sys.implementation.name`)
|
interpreter
|
Rótulo; o padrão é None
Para um ambiente de execução no build, esse é o destino a ser invocado como o interpretador. Ele
pode ser um dos seguintes:
* Um único arquivo, que será o binário do interpretador. Supõe-se que esses intérpretes sejam executáveis autônomos de arquivo único ou que todos os arquivos de suporte sejam especificados em "files".* Um destino executável. O executável do destino será o binário do interpretador.
Qualquer outra saída padrão (`target.files`) e arquivos simples runfiles
(`runfiles.files`) serão incluídos automaticamente como se fossem especificados no
atributo `files`.
OBSERVAÇÃO: os runfiles do destino ainda podem não ser respeitados/propagados corretamente
para consumidores da cadeia de ferramentas/interpretador. Consulte
bazelbuild/rules_python/issues/1612
Para um ambiente de execução de plataforma (ou seja, `interpreter_path` definido), esse atributo não pode
ser definido.
|
interpreter_path
|
String; o padrão é ""
Para um ambiente de execução de plataforma, esse é o caminho absoluto de um interpretador Python na
plataforma de destino. Para um ambiente de execução integrado, esse atributo não pode ser definido.
|
interpreter_version_info
|
Dicionário: String -> String; o padrão é {}
Informações da versão sobre o interpretador fornecido por esse ambiente de execução.
Se não for especificado, usará {obj}`--python_version`
As chaves compatíveis correspondem aos nomes de "sys.version_info". Embora os valores de entrada sejam strings, a maioria é convertida em números inteiros. As chaves compatíveis são:
* major: int, o número da versão principal
* minor: int, o número da versão secundária
* micro: int opcional, o número da versão micro
* releaselevel: str opcional, o nível de lançamento
* serial: int opcional, o número de série do lançamento
:::{versionchanged} 0.36.0
{obj}`--python_version` determina o valor padrão.
:::
|
pyc_tag
|
String; o padrão é ""
String opcional. A parte da tag de um nome de arquivo pyc, por exemplo, o infixo "cpython-39"
de "foo.cpython-39.pyc". Consulte a PEP 3147. Se não for especificado, ele será calculado com base em "implementation_name" e "interpreter_version_info". Se nenhuma pyc_tag estiver disponível, apenas a geração de pyc sem origem vai funcionar corretamente.
|
python_version
|
String; o padrão é "PY3"
Indica se este ambiente de execução é para a versão principal 2 ou 3 do Python. Os valores válidos são `"PY2"`
e `"PY3"`.
O valor padrão é controlado pela flag `--incompatible_py3_is_default`.
No entanto, no futuro, esse atributo será obrigatório e não terá um valor padrão.
|
stage2_bootstrap_template
|
Rótulo; o padrão é "@rules_python//python/private:stage2_bootstrap_template"
O modelo a ser usado quando a inicialização de duas fases está ativada.
:::{seealso}
{obj}`PyRuntimeInfo.stage2_bootstrap_template` e {obj}`--bootstrap_impl`
:::
|
stub_shebang
|
String; o padrão é "#!/usr/bin/env python3"
Expressão "Shebang" adicionada ao script stub Python de bootstrap
usado ao executar destinos {rule}`py_binary`.
Consulte https://github.com/bazelbuild/bazel/issues/8685 para
motivação.
Não se aplica ao Windows.
|
zip_main_template
|
Rótulo; o padrão é "@rules_python//python/private:zip_main_template"
O modelo a ser usado para o arquivo `__main__.py` de nível superior de um zip.
Esse se torna o ponto de entrada executado quando `python foo.zip` é executado.
::{seealso}
O campo {obj}`PyRuntimeInfo.zip_main_template`.
:::
|
