Report an issueopen_in_new
View sourceopen_in_new
Nightly
·
7.4
.
7.3
·
7.2
·
7.1
·
7.0
·
6.5
Regras
py_binary
Acessar a 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 outras bibliotecas que serão vinculadas ao destino.
Consulte os comentários sobre
o atributo `deps`, normalmente definido por
regras (link em inglês).
Essas são geralmente regras "py_library".
Os destinos que fornecem apenas arquivos de dados usados no momento da execução pertencem ao atributo
"data".
|
srcs
|
Lista de rótulos; obrigatório
A lista de arquivos de origem Python que são processados para criar o destino. Isso
inclui todo o código enviado e pode incluir arquivos de origem gerados. Os arquivos
`.py` pertencem a `srcs`, e os destinos da biblioteca pertencem a `deps`. Outros arquivos
binários que podem ser necessários no momento da execução pertencem a `data`.
|
data
|
Lista de rótulos; o padrão é []
A lista de arquivos necessários para essa biblioteca no momento da 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á "py_embed_data", como há "cc_embed_data" e "go_embed_data".
Isso ocorre porque o Python tem um conceito de recursos 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 "Fazer variável". Esses diretórios de importação serão adicionados
para essa regra e todas as regras que dependem dela (não as regras em que essa regra
depende). Cada diretório será adicionado a "PYTHONPATH" pelas regras "py_binary"
que dependem dessa regra. As strings são relativas à raiz de runfiles do repositório.
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
|
Inteiro; padrão é -1
Define se os arquivos "__init__.py" vazios serão criados implicitamente na árvore de arquivos de execução.
Elas são criadas em todos os diretórios que contêm código-fonte do Python ou bibliotecas
compartilhadas e em todos os diretórios pais desses diretórios, excluindo 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 falso, o usuário será
responsável por criar arquivos "__init__.py" (possivelmente vazios) e adicioná-los a
"srcs" de destinos do Python conforme necessário.
|
main
|
Rótulo: o padrão é None.
Opcional: o nome do arquivo de origem que é o ponto de entrada principal do
aplicativo. Esse arquivo também precisa ser listado em "srcs". Se não for especificado,
"name", com ".py" anexado, será usado. Se "name" não corresponder a nenhum
nome de arquivo em "srcs", será necessário especificar "main".
|
precompile
|
String; o padrão é "inherit"
Define se os arquivos de origem py **desta meta** precisam ser pré-compilados.
Valores:
* `inherit`: determina o valor da flag {flag}`--precompile`.
* "enabled": compila arquivos de origem do Python no momento da criação. A opção
--precompile_add_to_runfiles afeta como os arquivos compilados são incluídos em
um binário downstream.
* "disabled": não compila arquivos de origem do Python no momento do build.
* `if_generated_source`: compila arquivos de origem do Python, mas apenas se eles forem um
arquivo gerado.
:::{seealso}
* A flag {flag}`--precompile`, que pode substituir esse atributo em alguns casos
e afetará todos os destinos durante a criação.
* O atributo {obj}`pyc_collection` para ativar transitivamente a pré-compilação por
destino.
* Os documentos sobre [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 precisam ser verificados para estarem 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 um código que
você pode modificar.
* `unchecked_hash`: sempre use o arquivo pyc. Não verifique o hash do pyc em relação ao
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
|
Inteiro; padrão é 0
O nível de otimização para arquivos pré-compilados.
Para mais informações sobre os níveis de otimização, consulte os documentos de
`optimize` da função `compile()` em https://docs.python.org/3/library/functions.html#compile.
NOTA: o valor "-1" significa "intérprete atual", que será o interpretador
usado _no momento da compilação, quando os pycs são gerados_, e não o interpretador usado no
momento da execução, quando o código é realmente executado.
|
precompile_source_retention
|
String; o padrão é "inherit"
Determina, quando um arquivo de origem é compilado, se o arquivo de origem é 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 fonte py original.
* omit_if_generated_source: mantenha a origem original se for um arquivo de origem
comum, mas omita-a se for um arquivo gerado.
|
pyc_collection
|
String; o padrão é "inherit"
Determina se os arquivos pyc das dependências precisam ser incluídos manualmente.
OBSERVAÇÃO: essa configuração só é útil com {flag}`--precompile_add_to_runfiles=decided_elsewhere`.
Os valores válidos são:
* `inherit`: herda o valor de {flag}`--pyc_collection`.
* `include_pyc`: adiciona arquivos pyc de dependências no binário (de
{obj}`PyInfo.transitive_pyc_files`.
* `disabled`: não adiciona explicitamente arquivos pyc de dependências. Os arquivos pyc ainda podem vir de dependências se um destino os incluir como
parte dos runfiles, como quando {obj}`--precompile_add_to_runfiles=always`
é usado.
|
python_version
|
String; o padrão é "PY3"
Desativado, não usado, não faz nada.
|
srcs_version
|
String; o padrão é "PY2AND3"
Desativado, não usado, não faz nada.
|
stamp
|
Inteiro; padrão é -1
Define se as informações de build serão codificadas no binário. Valores possíveis:
* `stamp = 1`: sempre carimba as informações do build no binário, mesmo em
builds `--nostamp`. **Evite essa configuração**, já que ela pode acabar
com o armazenamento em cache remoto do binário e de qualquer ação downstream que dependa dele.
* "stamp = 0": sempre substitua as informações de build por valores constantes. Isso fornece
um bom armazenamento em cache de resultados de build.
* "stamp = -1": a incorporação de informações do build é controlada pela flag
`--[no]stamp`.
Os binários carimbados não são reconstruídos, a menos que as dependências mudem.
AVISO: a marcação pode prejudicar o desempenho do build ao reduzir as correspondências de cache e deve
ser evitada, se possível.
|
py_library
Confira a 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 em que se pode confiar.
Saídas padrão:
* As origens do Python de entrada
* Os artefatos pré-compilados das origens.
OBSERVAÇÃO: a pré-compilação afeta quais das saídas padrão são incluídas nos
arquivos de execução resultantes. Consulte os atributos e sinalizações relacionados à pré-compilação para
mais informações.
Argumentos
| Atributos |
name |
Nome: obrigatório
Um nome exclusivo para essa segmentação.
|
deps
|
Lista de rótulos; o padrão é []
Lista de outras bibliotecas que serão vinculadas ao destino.
Consulte os comentários sobre
o atributo `deps`, normalmente definido por
regras (link em inglês).
Essas são geralmente regras "py_library".
Os destinos que fornecem apenas arquivos de dados usados no momento da execução pertencem ao atributo
"data".
|
srcs
|
Lista de rótulos; o padrão é []
A lista de arquivos de origem Python que são processados para criar o destino. Isso
inclui todo o código enviado e pode incluir arquivos de origem gerados. Os arquivos
`.py` pertencem a `srcs`, e os destinos da biblioteca pertencem a `deps`. Outros arquivos
binários que podem ser necessários no momento da execução pertencem a `data`.
|
data
|
Lista de rótulos; o padrão é []
A lista de arquivos necessários para essa biblioteca no momento da 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á "py_embed_data", como há "cc_embed_data" e "go_embed_data".
Isso ocorre porque o Python tem um conceito de recursos 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 "Fazer variável". Esses diretórios de importação serão adicionados
para essa regra e todas as regras que dependem dela (não as regras em que essa regra
depende). Cada diretório será adicionado a "PYTHONPATH" pelas regras "py_binary"
que dependem dessa regra. As strings são relativas à raiz de runfiles do repositório.
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"
Define se os arquivos de origem py **desta meta** precisam ser pré-compilados.
Valores:
* `inherit`: determina o valor da flag {flag}`--precompile`.
* "enabled": compila arquivos de origem do Python no momento da criação. A opção
--precompile_add_to_runfiles afeta como os arquivos compilados são incluídos em
um binário downstream.
* "disabled": não compila arquivos de origem do Python no momento do build.
* `if_generated_source`: compila arquivos de origem do Python, mas apenas se eles forem um
arquivo gerado.
:::{seealso}
* A flag {flag}`--precompile`, que pode substituir esse atributo em alguns casos
e afetará todos os destinos durante a criação.
* O atributo {obj}`pyc_collection` para ativar transitivamente a pré-compilação por
destino.
* Os documentos sobre [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 precisam ser verificados para estarem 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 um código que
você pode modificar.
* `unchecked_hash`: sempre use o arquivo pyc. Não verifique o hash do pyc em relação ao
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
|
Inteiro; padrão é 0
O nível de otimização para arquivos pré-compilados.
Para mais informações sobre os níveis de otimização, consulte os documentos de
`optimize` da função `compile()` em https://docs.python.org/3/library/functions.html#compile.
NOTA: o valor "-1" significa "intérprete atual", que será o interpretador
usado _no momento da compilação, quando os pycs são gerados_, e não o interpretador usado no
momento da execução, quando o código é realmente executado.
|
precompile_source_retention
|
String; o padrão é "inherit"
Determina, quando um arquivo de origem é compilado, se o arquivo de origem é 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 fonte py original.
* omit_if_generated_source: mantenha a origem original se for um arquivo de origem
comum, mas omita-a se for um arquivo gerado.
|
srcs_version
|
String; o padrão é "PY2AND3"
Desativado, não usado, não faz nada.
|
py_test
Acessar a 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 outras bibliotecas que serão vinculadas ao destino.
Consulte os comentários sobre
o atributo `deps`, normalmente definido por
regras (link em inglês).
Essas são geralmente regras "py_library".
Os destinos que fornecem apenas arquivos de dados usados no momento da execução pertencem ao atributo
"data".
|
srcs
|
Lista de rótulos; obrigatório
A lista de arquivos de origem Python que são processados para criar o destino. Isso
inclui todo o código enviado e pode incluir arquivos de origem gerados. Os arquivos
`.py` pertencem a `srcs`, e os destinos da biblioteca pertencem a `deps`. Outros arquivos
binários que podem ser necessários no momento da execução pertencem a `data`.
|
data
|
Lista de rótulos; o padrão é []
A lista de arquivos necessários para essa biblioteca no momento da 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á "py_embed_data", como há "cc_embed_data" e "go_embed_data".
Isso ocorre porque o Python tem um conceito de recursos 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 "Fazer variável". Esses diretórios de importação serão adicionados
para essa regra e todas as regras que dependem dela (não as regras em que essa regra
depende). Cada diretório será adicionado a "PYTHONPATH" pelas regras "py_binary"
que dependem dessa regra. As strings são relativas à raiz de runfiles do repositório.
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
|
Inteiro; padrão é -1
Define se os arquivos "__init__.py" vazios serão criados implicitamente na árvore de arquivos de execução.
Elas são criadas em todos os diretórios que contêm código-fonte do Python ou bibliotecas
compartilhadas e em todos os diretórios pais desses diretórios, excluindo 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 falso, o usuário será
responsável por criar arquivos "__init__.py" (possivelmente vazios) e adicioná-los a
"srcs" de destinos do Python conforme necessário.
|
main
|
Rótulo: o padrão é None.
Opcional: o nome do arquivo de origem que é o ponto de entrada principal do
aplicativo. Esse arquivo também precisa ser listado em "srcs". Se não for especificado,
"name", com ".py" anexado, será usado. Se "name" não corresponder a nenhum
nome de arquivo em "srcs", será necessário especificar "main".
|
precompile
|
String; o padrão é "inherit"
Define se os arquivos de origem py **desta meta** precisam ser pré-compilados.
Valores:
* `inherit`: determina o valor da flag {flag}`--precompile`.
* "enabled": compila arquivos de origem do Python no momento da criação. A opção
--precompile_add_to_runfiles afeta como os arquivos compilados são incluídos em
um binário downstream.
* "disabled": não compila arquivos de origem do Python no momento do build.
* `if_generated_source`: compila arquivos de origem do Python, mas apenas se eles forem um
arquivo gerado.
:::{seealso}
* A flag {flag}`--precompile`, que pode substituir esse atributo em alguns casos
e afetará todos os destinos durante a criação.
* O atributo {obj}`pyc_collection` para ativar transitivamente a pré-compilação por
destino.
* Os documentos sobre [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 precisam ser verificados para estarem 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 um código que
você pode modificar.
* `unchecked_hash`: sempre use o arquivo pyc. Não verifique o hash do pyc em relação ao
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
|
Inteiro; padrão é 0
O nível de otimização para arquivos pré-compilados.
Para mais informações sobre os níveis de otimização, consulte os documentos de
`optimize` da função `compile()` em https://docs.python.org/3/library/functions.html#compile.
NOTA: o valor "-1" significa "intérprete atual", que será o interpretador
usado _no momento da compilação, quando os pycs são gerados_, e não o interpretador usado no
momento da execução, quando o código é realmente executado.
|
precompile_source_retention
|
String; o padrão é "inherit"
Determina, quando um arquivo de origem é compilado, se o arquivo de origem é 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 fonte py original.
* omit_if_generated_source: mantenha a origem original se for um arquivo de origem
comum, mas omita-a se for um arquivo gerado.
|
pyc_collection
|
String; o padrão é "inherit"
Determina se os arquivos pyc das dependências precisam ser incluídos manualmente.
OBSERVAÇÃO: essa configuração só é útil com {flag}`--precompile_add_to_runfiles=decided_elsewhere`.
Os valores válidos são:
* `inherit`: herda o valor de {flag}`--pyc_collection`.
* `include_pyc`: adiciona arquivos pyc de dependências no binário (de
{obj}`PyInfo.transitive_pyc_files`.
* `disabled`: não adiciona explicitamente arquivos pyc de dependências. Os arquivos pyc ainda podem vir de dependências se um destino os incluir como
parte dos runfiles, como quando {obj}`--precompile_add_to_runfiles=always`
é usado.
|
python_version
|
String; o padrão é "PY3"
Desativado, não usado, não faz nada.
|
srcs_version
|
String; o padrão é "PY2AND3"
Desativado, não usado, não faz nada.
|
stamp
|
Inteiro; padrão é 0
Define se as informações de build serão codificadas no binário. Valores possíveis:
* `stamp = 1`: sempre carimba as informações do build no binário, mesmo em
builds `--nostamp`. **Evite essa configuração**, já que ela pode acabar
com o armazenamento em cache remoto do binário e de qualquer ação downstream que dependa dele.
* "stamp = 0": sempre substitua as informações de build por valores constantes. Isso fornece
um bom armazenamento em cache de resultados de build.
* "stamp = -1": a incorporação de informações do build é controlada pela flag
`--[no]stamp`.
Os binários carimbados não são reconstruídos, a menos que as dependências mudem.
AVISO: a marcação pode prejudicar o desempenho do build ao reduzir as correspondências de cache e deve
ser evitada, se possível.
|
py_runtime
Conferir a origem da regraopen_in_new
py_runtime(name, 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 o código Python.
Um destino "py_runtime" pode representar um *ambiente de execução da plataforma* ou um *ambiente de execução
integrado*. Um ambiente de execução da plataforma acessa um interpretador instalado pelo sistema em um caminho
conhecido, enquanto um ambiente de execução integrado aponta para um destino executável que atua como
o interpretador. Em ambos os casos, um "intérprete" significa qualquer script binário executável ou
wrapper capaz de executar um script Python transmitido na linha
de comando, seguindo as mesmas convenções do interpretador CPython padrão.
Por natureza, o ambiente de execução da plataforma não é hermético. Ele impõe um requisito à
plataforma de destino para ter um intérprete localizado em um caminho específico. Um
ambiente de execução integrado pode ou não ser hermético, dependendo se ele aponta para
um interpretador registrado 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.
|
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 por ações iniciais de inicialização, 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 do próprio Bazel.
Os nomes de variáveis exatos expandidos 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 movidas para fora do Bazel.
Consulte @bazel_tools//tools/python:python_bootstrap_template.txt para conferir mais variáveis.
|
coverage_tool
|
Rótulo: o padrão é None.
É um destino a ser usado para coletar informações de cobertura de código de
{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 único arquivo ou o executável, se o destino for executável,
determina o ponto de entrada da ferramenta de cobertura do Python. O alvo e os
runfiles serão adicionados aos runfiles quando a cobertura for ativada.
O ponto de entrada da ferramenta precisa ser carregado por um interpretador do Python (por exemplo, um
arquivo ".py" ou ".pyc"). Ele precisa aceitar os argumentos de 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 integrado, esse é o conjunto de arquivos que compõem esse ambiente.
Esses arquivos serão adicionados aos arquivos de execução de binários Python que usam esse
ambiente de execução. Para um ambiente de execução de plataforma, esse atributo não precisa ser definido.
|
implementation_name
|
String; o padrão é ""
O nome da implementação do Python (`sys.implementation.name`)
|
interpreter
|
Rótulo: o padrão é None.
Para um ambiente de execução integrado, esse é o destino a ser invocado como intérprete. Ele
pode ser:
* Um único arquivo, que será o binário do interpretador. Supõe-se que esses
intérpretes sejam executáveis independentes de um único arquivo ou que qualquer
arquivo de suporte seja especificado em "files".
* Um destino executável. O executável do destino será o binário do interpretador.
Todas as outras saídas padrão (`target.files`) e arquivos simples runfiles
(`runfiles.files`) serão incluídas automaticamente como se tivessem sido especificadas no
atributo "files".
OBSERVAÇÃO: os arquivos de execução do destino talvez ainda não sejam respeitados/propagados corretamente
para os consumidores do conjunto de ferramentas/intérprete. Consulte
bazelbuild/rules_python/issues/1612
Para um ambiente de execução de plataforma (ou seja, "interpreter_path" sendo 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 precisa ser definido.
|
interpreter_version_info
|
Dicionário: String -> String; o padrão é {}
Informações de versão sobre o interpretador fornecido por esse ambiente de execução.
Se não for especificado, {obj}`--python_version` será usado.
As chaves com suporte 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 da versão
:::{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 PEP 3147. Se não for especificado, ele será computado
a partir de "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 o 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á valor
padrão.
|
stage2_bootstrap_template
|
Rótulo: o padrão é "@rules_python//python/private:stage2_bootstrap_template".
O modelo a ser usado quando o bootstrap de dois estágios está ativado
:::{seealso}
{obj}`PyRuntimeInfo.stage2_bootstrap_template` e {obj}`--bootstrap_impl`
:::
|
stub_shebang
|
String; o padrão é "#!/usr/bin/env python3"
A expressão "Shebang" foi adicionada ao script de stubs de inicialização do Python
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 arquivo ZIP.
Esse é o ponto de entrada executado quando "python foo.zip" é executado.
:::{seealso}
O campo {obj}`PyRuntimeInfo.zip_main_template`.
:::
|
