Regras do Python

Informar um problema Ver fonte Nightly · 8.3 · 8.2 · 8.1 ·

Regras

py_binary

Ver origem da regra
py_binary(name, deps, srcs, data, args, 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".
srcs

Lista de marcadores; obrigatório

A lista de arquivos de origem Python processados para criar o destino. Isso inclui todo o código registrado e pode incluir arquivos de origem gerados. Os arquivos `.py` pertencem a `srcs`, e os destinos de biblioteca pertencem a `deps`. Outros arquivos binários que podem ser necessários no tempo de execução pertencem a `data`.
data

Lista de rótulos. O padrão é [].

A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte os comentários sobre o atributo [`data` normalmente definido por regras](https://bazel.build/reference/be/common-definitions#typical-attributes). Não há um `py_embed_data` como `cc_embed_data` e `go_embed_data`, porque o Python tem um conceito de recursos de tempo de execução.
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 ela 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 interpretador. Os argumentos compatíveis com um interpretador são específicos dele. Para CPython, consulte https://docs.python.org/3/using/cmdline.html. ::{note} Compatível apenas com {obj}`--bootstrap_impl=script`. Caso contrário, será ignorado. ::: :::{seealso} A variável de ambiente {obj}`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. * A documentação 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 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 _durante o build quando os pycs são gerados_, não o interpretador usado durante a 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 pacote 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 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 regra
py_library(name, deps, srcs, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_group_compatible_with, exec_properties, 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 Python de entrada * Os artefatos pré-compilados das fontes. OBSERVAÇÃO: a pré-compilação afeta quais das saídas padrão são incluídas nos runfiles resultantes. Consulte os atributos e flags relacionados à pré-compilação para mais informações. ::{versionchanged} 0.37.0 Os arquivos de origem não são mais adicionados diretamente aos runfiles. :::

Argumentos

Atributos
name

Nome: obrigatório

Um nome exclusivo para essa segmentação.

deps

Lista de rótulos. O padrão é [].

Lista de bibliotecas adicionais a serem vinculadas ao destino. Consulte os comentários sobre o atributo [`deps` normalmente definido por regras](https://bazel.build/reference/be/common-definitions#typical-attributes). Normalmente, são regras "py_library". Os destinos que fornecem apenas arquivos de dados usados no tempo de execução pertencem ao atributo "data".
srcs

Lista de rótulos. O padrão é [].

A lista de arquivos de origem Python processados para criar o destino. Isso inclui todo o código registrado e pode incluir arquivos de origem gerados. Os arquivos `.py` pertencem a `srcs`, e os destinos de biblioteca pertencem a `deps`. Outros arquivos binários que podem ser necessários no tempo de execução pertencem a `data`.
data

Lista de rótulos. O padrão é [].

A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte os comentários sobre o atributo [`data` normalmente definido por regras](https://bazel.build/reference/be/common-definitions#typical-attributes). Não há um `py_embed_data` como `cc_embed_data` e `go_embed_data`, porque o Python tem um conceito de recursos de tempo de execução.
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 ela 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. * A documentação 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 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 _durante o build quando os pycs são gerados_, não o interpretador usado durante a 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 pacote 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 regra
py_test(name, deps, srcs, data, args, 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".
srcs

Lista de marcadores; obrigatório

A lista de arquivos de origem Python processados para criar o destino. Isso inclui todo o código registrado e pode incluir arquivos de origem gerados. Os arquivos `.py` pertencem a `srcs`, e os destinos de biblioteca pertencem a `deps`. Outros arquivos binários que podem ser necessários no tempo de execução pertencem a `data`.
data

Lista de rótulos. O padrão é [].

A lista de arquivos necessários para essa biblioteca no tempo de execução. Consulte os comentários sobre o atributo [`data` normalmente definido por regras](https://bazel.build/reference/be/common-definitions#typical-attributes). Não há um `py_embed_data` como `cc_embed_data` e `go_embed_data`, porque o Python tem um conceito de recursos de tempo de execução.
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 ela 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 interpretador. Os argumentos compatíveis com um interpretador são específicos dele. Para CPython, consulte https://docs.python.org/3/using/cmdline.html. ::{note} Compatível apenas com {obj}`--bootstrap_impl=script`. Caso contrário, será ignorado. ::: :::{seealso} A variável de ambiente {obj}`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. * A documentação 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 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 _durante o build quando os pycs são gerados_, não o interpretador usado durante a 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 pacote 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 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 regra
py_runtime(name, abi_flags, 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 de ABI do tempo de execução, ou seja, "sys.abiflags". Se não estiver 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 removidas 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 de 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 destes: * 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 runfiles de arquivos simples (`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`. :::