Informar um problemaopen_in_new
Mostrar fonteopen_in_new
Por noite
·
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 a serem vinculadas ao destino.
Consulte os comentários sobre
o atributo `deps`, que geralmente é definido por
regras (link em inglês).
Geralmente, são regras de `py_library`.
Os destinos que fornecem apenas arquivos de dados usados no ambiente de execução pertencem ao campo "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 verificado 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 esta biblioteca no tempo de execução. Ler comentários sobre
o [atributo "data" normalmente definido por regras](https://bazel.build/reference/be/common-definitions#typical-attributes).
Não existe `py_embed_data` como há `cc_embed_data` e `go_embed_data`.
Isso ocorre porque o Python tem um conceito de recursos de ambiente de execução.
|
imports
|
Lista de strings. O padrão é [].
Lista de diretórios de importação a serem adicionados ao PYTHONPATH.
Sujeito a "Criar variável" substituta. Esses diretórios de importação serão adicionados
para esta regra e todas as regras que dependem dela (observação: não são as regras
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 resultarão em um erro.
|
legacy_create_init
|
Integer; o padrão é -1
Define se arquivos "__init__.py" vazios são implicitamente criados 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 verdadeiro, a menos que
"--incompatíveis_default_to_explicit_init_py" será usado. Se for falso, o usuário será
responsável por criar arquivos `__init__.py` (possivelmente vazios) e adicioná-los ao
os "srcs" dos destinos 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 do arquivo em `srcs`, o `main` precisa ser especificado.
|
precompile
|
String; o padrão é "inherit"
Define se os arquivos de origem py **desta meta** precisam ser pré-compilados.
Valores:
* `herança`: 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 Python, mas somente se forem
arquivo gerado.
:::{seealso}
* A sinalização {flag}`--precompile`, que pode substituir esse atributo em alguns casos
e vai 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 é necessário verificar se os arquivos pré-compilados estão atualizados com os arquivos
arquivos de origem. 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 usar o arquivo pyc; não verifique o hash de pyc em relação
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
|
Integer; o padrão é 0
O nível de otimização para arquivos pré-compilados.
Para obter mais informações sobre níveis de otimização, consulte o tópico da função `compile()`
Documentos arg `optimize` em https://docs.python.org/3/library/functions.html#compile
OBSERVAÇÃO: o valor "-1" significa "interpretador atual", que será o intérprete
usado _no tempo de compilação quando os pycs são gerados_, não o intérprete usado em
no ambiente de execução quando o código é realmente 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:
* `herança`: 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.
* 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:
* `herdado`: herda o valor de {flag}`--pyc_collection`.
* `include_pyc`: adiciona arquivos pyc de dependências no binário (de
{obj}`PyInfo.transitive_pyc_files`.
* `desativado`: não adicione explicitamente arquivos pyc das 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"
Expirada, não utilizada, não faz nada.
|
srcs_version
|
String; o padrão é "PY2AND3"
Desativado, não usado, não faz nada.
|
stamp
|
Integer; o padrão é -1
Define se as informações de build serão codificadas no binário. Valores possíveis:
* `stamp = 1`: sempre carimbe as informações da versão no binário, mesmo em
`--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 compilação por valores constantes. Isso dá
um bom armazenamento em cache dos resultados da compilação.
* "stamp = -1": a incorporação de informações de build é controlada pela flag
`--[no]stamp`.
Binários carimbos não são recompilados, a menos que as dependências deles mudem.
AVISO: a estampa pode prejudicar o desempenho do build ao reduzir ocorrências em cache e deve
devem ser evitados, se possível.
|
py_library
Acessar 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 você pode contar.
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 as flags 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.
Ler comentários sobre
o atributo [`deps` normalmente definido pelo
rules](https://bazel.build/reference/be/common-definitions#typical-attributes).
Essas são geralmente regras "py_library".
Os destinos que fornecem apenas arquivos de dados usados no ambiente de execução pertencem ao campo "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 esta biblioteca no tempo de execução. Ler comentários sobre
o [atributo "data" normalmente definido por regras](https://bazel.build/reference/be/common-definitions#typical-attributes).
Não existe `py_embed_data` como há `cc_embed_data` e `go_embed_data`.
Isso ocorre porque o Python tem um conceito de recursos de ambiente de execução.
|
imports
|
Lista de strings. O padrão é [].
Lista de diretórios de importação a serem adicionados ao PYTHONPATH.
Sujeito a "Criar variável" substituta. 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:
* `herança`: 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 Python, mas somente se forem
arquivo gerado.
:::{seealso}
* A sinalização {flag}`--precompile`, que pode substituir esse atributo em alguns casos
e vai 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 é necessário verificar se os arquivos pré-compilados estão atualizados com os arquivos
arquivos de origem. 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 usar o arquivo pyc; não verifique o hash de pyc em relação
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
|
Integer; o padrão é 0
O nível de otimização para arquivos pré-compilados.
Para obter mais informações sobre níveis de otimização, consulte o tópico da função `compile()`
Documentos arg `optimize` em https://docs.python.org/3/library/functions.html#compile
OBSERVAÇÃO: o valor "-1" significa "interpretador atual", que será o intérprete
usado _no tempo de compilação quando os pycs são gerados_, não o intérprete usado em
no ambiente de 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:
* `herança`: 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`: mantém a origem original se ela for regular.
mas omita-o 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 o destino.
|
deps
|
Lista de rótulos; o padrão é []
Lista de outras bibliotecas que serão vinculadas ao destino.
Ler comentários sobre
o atributo [`deps` normalmente definido pelo
rules](https://bazel.build/reference/be/common-definitions#typical-attributes).
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 esta 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á "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 a "Criar variável" substituta. Esses diretórios de importação serão adicionados
para esta regra e todas as regras que dependem dela (observação: não são as regras
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 resultarão em um erro.
|
legacy_create_init
|
Integer; o padrão é -1
Define se os arquivos "__init__.py" vazios serão criados implicitamente 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 e todos os diretórios pai desses diretórios, exceto o repositório
diretório raiz. 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 fonte que é o ponto de entrada principal do
para o 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:
* `herança`: 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 Python, mas somente se forem
arquivo gerado.
:::{seealso}
* A sinalização {flag}`--precompile`, que pode substituir esse atributo em alguns casos
e vai 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 é necessário verificar se os arquivos pré-compilados estão atualizados com os arquivos
arquivos de origem. 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 usar o arquivo pyc; não verifique o hash de pyc em relação
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
|
Integer; o padrão é 0
O nível de otimização para arquivos pré-compilados.
Para obter mais informações sobre níveis de otimização, consulte o tópico da função `compile()`
Documentos arg `optimize` em https://docs.python.org/3/library/functions.html#compile
OBSERVAÇÃO: o valor "-1" significa "interpretador atual", que será o intérprete
usado _no tempo de compilação quando os pycs são gerados_, não o intérprete usado em
no ambiente de execução quando o código é realmente 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:
* `herança`: 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.
* 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:
* `herdado`: herda o valor de {flag}`--pyc_collection`.
* `include_pyc`: adiciona arquivos pyc de dependências no binário (de
{obj}`PyInfo.transitive_pyc_files`.
* `desativado`: não adicione explicitamente arquivos pyc das 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"
Expirada, não utilizada, não faz nada.
|
srcs_version
|
String; o padrão é "PY2AND3"
Expirada, não utilizada, não faz nada.
|
stamp
|
Inteiro; padrão é 0
Define se as informações da versão 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 dá
um bom armazenamento em cache dos resultados da compilação.
* "stamp = -1": a incorporação de informações do build é controlada pela flag
`--[no]stamp`.
Os binários marcados não são reconstruídos, a menos que as dependências mudem.
AVISO: a estampa pode prejudicar o desempenho do build ao reduzir ocorrências em cache e deve
devem ser evitados, 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 código Python.
Um destino "py_runtime" pode representar um *ambiente de execução de plataforma* ou um *em build
de execução*. O ambiente de execução da plataforma acessa um interpretador instalado pelo sistema em uma
enquanto um ambiente de execução em build aponta para um destino executável que atua como
o intérprete. 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.
O ambiente de execução da plataforma é, por sua natureza, não hermético. Ela impõe um requisito
plataforma de destino para que um intérprete esteja 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 para fora do 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 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 destino e os
runfiles serão adicionados aos runfiles quando a cobertura estiver ativada.
O ponto de entrada da ferramenta deve ser carregável por um intérprete de 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 em build, esse é o conjunto de arquivos desse ambiente.
Esses arquivos serão adicionados aos arquivos de execução de binários Python que usam esse
no 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 de 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. Ela
pode ser:
* Um único arquivo, que será o binário do intérprete. Presume-se que essas
os intérpretes são executáveis de um único arquivo ou quaisquer
de suporte são especificados 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 runfiles 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, usa {obj}`--python_version`
As chaves compatíveis correspondem aos nomes de "sys.version_info". Embora a entrada
valores são strings, a maioria é convertida em ints. 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
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"
Se esse 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 sinalização "--incompatíveis_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"
"Shebang" expressão anexada ao script de stub do Python de bootstrapping
usada ao executar destinos {rule}`py_binary`.
Consulte https://github.com/bazelbuild/bazel/issues/8685 para
e 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.
Ele se torna o ponto de entrada executado quando "python foo.zip" é executado.
:::{seealso}
O campo {obj}`PyRuntimeInfo.zip_main_template`.
:::
|
