Reportar um problemaopen_in_new
Ver a fonteopen_in_new
Nightly
·
8.4
·
8.3
·
8.2
·
8.1
·
8.0
·
7.6
Regras
py_binary
Ver origem da regraopen_in_new
py_binary(name, deps, srcs, data, args, aspect_hints, compatible_with, deprecation, distribs, env, exec_compatible_with, exec_group_compatible_with, exec_properties, features, imports, interpreter_args, legacy_create_init, licenses, main, main_module, output_licenses, package_metadata, precompile, precompile_invalidation_mode, precompile_optimize_level, precompile_source_retention, pyc_collection, pyi_deps, pyi_srcs, 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".
::{note}
A ordem dessa lista pode ser importante porque afeta a ordem em que as informações
das dependências são mescladas, o que pode ser relevante dependendo do modo de ordenação
dos conjuntos de dependências mesclados.
* {obj}`PyInfo.site_packages_symlinks` usa ordenação topológica.
Consulte {obj}`PyInfo` para mais informações sobre a ordenação dos depsets e
como os campos são mesclados.
:::
|
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.
|
distribs
|
Lista de strings. O padrã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.
|
interpreter_args
|
Lista de strings. O padrão é [].
Argumentos aplicáveis apenas ao intérprete.
Os argumentos que um interpretador aceita são específicos dele. Para
CPython, consulte https://docs.python.org/3/using/cmdline.html.
:::{note}
Só é compatível com {obj}`--bootstrap_impl=script`. Caso contrário, é ignorado.
::
:::{seealso}
A variável de ambiente {any}`RULES_PYTHON_ADDITIONAL_INTERPRETER_ARGS`
:::
:::{versionadded} 1.3.0
:::
|
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.
Isso é mutuamente exclusivo com {obj}`main_module`.
|
main_module
|
String; o padrão é ""
Nome do módulo a ser executado como o programa principal.
Quando definido, "srcs" não é obrigatório, e presume-se que o módulo seja
fornecido por uma dependência.
Consulte https://docs.python.org/3/using/cmdline.html#cmdoption-m para mais informações sobre como executar módulos como o programa principal.
Isso é mutuamente exclusivo com {obj}`main`.
:::{versionadded} 1.3.0
:::
|
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.
|
pyi_deps
|
Lista de rótulos. O padrão é [].
Dependências que fornecem as definições de tipo necessárias para a biblioteca.
São dependências que atendem a importações protegidas por `typing.TYPE_CHECKING`.
Elas são dependências somente de tempo de build e não são incluídas como parte de um programa
executável (mas as regras de pacote podem incluí-las).
::{versionadded} 1.1.0
:::
|
pyi_srcs
|
Lista de rótulos. O padrão é [].
Arquivos de definição de tipo para a biblioteca.
Normalmente, são arquivos `.pyi`, mas outros tipos de arquivos para formatos específicos do verificador de tipos são permitidos. Esses arquivos são dependências somente de tempo de build e não são incluídos
como parte de um programa executável (mas as regras de empacotamento podem incluí-los).
::{versionadded} 1.1.0
:::
|
python_version
|
String; o padrão é ""
A versão do Python que esse destino deve usar.
O valor precisa estar no formato "X.Y" ou "X.Y.Z" (ou compatível). Se estiver vazio ou não especificado, a flag {obj}`--python_version` da configuração de entrada será herdada. Para compatibilidade com versões anteriores, os valores "PY2" e "PY3" são aceitos, mas tratados como um valor vazio/não especificado.
:::{note}
Para que a versão solicitada seja usada, é necessário ter uma
cadeia de ferramentas configurada para corresponder à versão do Python. Se não houver, ele poderá ser ignorado silenciosamente ou ocorrer um erro, dependendo da configuração da cadeia de ferramentas.
:::
:::{versionchanged} 1.1.0
Esse atributo foi alterado para aceitar versões arbitrárias do Python, e não apenas valores `PY2` e `PY3`.
:::
|
srcs_version
|
String; o padrão é ""
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, aspect_hints, compatible_with, deprecation, distribs, exec_compatible_with, exec_group_compatible_with, exec_properties, experimental_venvs_site_packages, features, imports, licenses, package_metadata, precompile, precompile_invalidation_mode, precompile_optimize_level, precompile_source_retention, pyi_deps, pyi_srcs, 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".
::{note}
A ordem dessa lista pode ser importante porque afeta a ordem em que as informações
das dependências são mescladas, o que pode ser relevante dependendo do modo de ordenação
dos conjuntos de dependências mesclados.
* {obj}`PyInfo.site_packages_symlinks` usa ordenação topológica.
Consulte {obj}`PyInfo` para mais informações sobre a ordenação dos depsets e
como os campos são mesclados.
:::
|
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.
|
distribs
|
Lista de strings. O padrão é [].
|
experimental_venvs_site_packages
|
Rótulo; o padrão é None
**INTERNAL ATTRIBUTE. SHOULD ONLY BE SET BY rules_python-INTERNAL CODE.**
::{include} /_includes/experimental_api.md
:::
Uma flag que decide se a biblioteca deve tratar as origens como um
layout de site-packages.
Quando a flag é "yes", os arquivos "srcs" são tratados como um layout de site-packages
relativo ao atributo "imports". O atributo "imports"
pode ter apenas um elemento. É um caminho de runfiles relativo ao repositório.
Por exemplo, no arquivo `my/pkg/BUILD.bazel`, considerando
`srcs=["site-packages/foo/bar.py"]`, especificar
`imports=["my/pkg/site-packages"]` significa que `foo/bar.py` é o caminho do arquivo
no diretório site-packages do venv binário que deve ser disponibilizado (ou seja,
`import foo.bar` vai funcionar).
Os arquivos "__init__.py" são tratados de maneira especial para oferecer suporte básico a [pacotes de namespace implícitos](https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages).
No entanto, o *conteúdo* dos arquivos não pode ser considerado, apenas a presença ou ausência deles. Em outras palavras, [pacotes de namespace no estilo pkgutil](
https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#pkgutil-style-namespace-packages)
não serão entendidos como pacotes de namespace, mas como pacotes regulares. Isso provavelmente vai gerar conflitos com outros destinos que contribuem para o namespace.
::{tip}
Esse atributo preenche {obj}`PyInfo.site_packages_symlinks`, que é
um conjunto de dependências ordenado topologicamente. Isso significa que as dependências mais próximas e anteriores a um consumidor têm precedência. Consulte {obj}`PyInfo.site_packages_symlinks` para
mais informações.
::
:::{versionadded} 1.4.0
:::
|
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.
|
pyi_deps
|
Lista de rótulos. O padrão é [].
Dependências que fornecem as definições de tipo necessárias para a biblioteca.
São dependências que atendem a importações protegidas por `typing.TYPE_CHECKING`.
Elas são dependências somente de tempo de build e não são incluídas como parte de um programa
executável (mas as regras de pacote podem incluí-las).
::{versionadded} 1.1.0
:::
|
pyi_srcs
|
Lista de rótulos. O padrão é [].
Arquivos de definição de tipo para a biblioteca.
Normalmente, são arquivos `.pyi`, mas outros tipos de arquivos para formatos específicos do verificador de tipos são permitidos. Esses arquivos são dependências somente de tempo de build e não são incluídos
como parte de um programa executável (mas as regras de empacotamento podem incluí-los).
::{versionadded} 1.1.0
:::
|
srcs_version
|
String; o padrão é ""
Extinto, não usado, não faz nada.
|
py_test
Ver origem da regraopen_in_new
py_test(name, deps, srcs, data, args, aspect_hints, compatible_with, deprecation, distribs, env, env_inherit, exec_compatible_with, exec_group_compatible_with, exec_properties, features, flaky, imports, interpreter_args, legacy_create_init, licenses, local, main, main_module, package_metadata, precompile, precompile_invalidation_mode, precompile_optimize_level, precompile_source_retention, pyc_collection, pyi_deps, pyi_srcs, 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".
::{note}
A ordem dessa lista pode ser importante porque afeta a ordem em que as informações
das dependências são mescladas, o que pode ser relevante dependendo do modo de ordenação
dos conjuntos de dependências mesclados.
* {obj}`PyInfo.site_packages_symlinks` usa ordenação topológica.
Consulte {obj}`PyInfo` para mais informações sobre a ordenação dos depsets e
como os campos são mesclados.
:::
|
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.
|
distribs
|
Lista de strings. O padrã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.
|
interpreter_args
|
Lista de strings. O padrão é [].
Argumentos aplicáveis apenas ao intérprete.
Os argumentos que um interpretador aceita são específicos dele. Para
CPython, consulte https://docs.python.org/3/using/cmdline.html.
:::{note}
Só é compatível com {obj}`--bootstrap_impl=script`. Caso contrário, é ignorado.
::
:::{seealso}
A variável de ambiente {any}`RULES_PYTHON_ADDITIONAL_INTERPRETER_ARGS`
:::
:::{versionadded} 1.3.0
:::
|
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.
Isso é mutuamente exclusivo com {obj}`main_module`.
|
main_module
|
String; o padrão é ""
Nome do módulo a ser executado como o programa principal.
Quando definido, "srcs" não é obrigatório, e presume-se que o módulo seja
fornecido por uma dependência.
Consulte https://docs.python.org/3/using/cmdline.html#cmdoption-m para mais informações sobre como executar módulos como o programa principal.
Isso é mutuamente exclusivo com {obj}`main`.
:::{versionadded} 1.3.0
:::
|
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.
|
pyi_deps
|
Lista de rótulos. O padrão é [].
Dependências que fornecem as definições de tipo necessárias para a biblioteca.
São dependências que atendem a importações protegidas por `typing.TYPE_CHECKING`.
Elas são dependências somente de tempo de build e não são incluídas como parte de um programa
executável (mas as regras de pacote podem incluí-las).
::{versionadded} 1.1.0
:::
|
pyi_srcs
|
Lista de rótulos. O padrão é [].
Arquivos de definição de tipo para a biblioteca.
Normalmente, são arquivos `.pyi`, mas outros tipos de arquivos para formatos específicos do verificador de tipos são permitidos. Esses arquivos são dependências somente de tempo de build e não são incluídos
como parte de um programa executável (mas as regras de empacotamento podem incluí-los).
::{versionadded} 1.1.0
:::
|
python_version
|
String; o padrão é ""
A versão do Python que esse destino deve usar.
O valor precisa estar no formato "X.Y" ou "X.Y.Z" (ou compatível). Se estiver vazio ou não especificado, a flag {obj}`--python_version` da configuração de entrada será herdada. Para compatibilidade com versões anteriores, os valores "PY2" e "PY3" são aceitos, mas tratados como um valor vazio/não especificado.
:::{note}
Para que a versão solicitada seja usada, é necessário ter uma
cadeia de ferramentas configurada para corresponder à versão do Python. Se não houver, ele poderá ser ignorado silenciosamente ou ocorrer um erro, dependendo da configuração da cadeia de ferramentas.
:::
:::{versionchanged} 1.1.0
Esse atributo foi alterado para aceitar versões arbitrárias do Python, e não apenas valores `PY2` e `PY3`.
:::
|
srcs_version
|
String; o padrão é ""
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, aspect_hints, bootstrap_template, compatible_with, coverage_tool, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, files, implementation_name, interpreter, interpreter_path, interpreter_version_info, package_metadata, pyc_tag, python_version, restricted_to, site_init_template, 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
interpretadores 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
bazel-contrib/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.
|
site_init_template
|
Rótulo; o padrão é "@rules_python//python/private:site_init_template"
O modelo a ser usado para o hook de inicialização do site específico do binário executado pelo
interpretador na inicialização.
:::{versionadded} 0.41.0
:::
|
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`.
:::
|
