Esta página foi traduzida pela API Cloud Translation.

Regras do Python

Informar um problema Ver código-fonte {19/Night} {19/Night} {19/Night}

Regras

py_binary

py_library

py_test

py_runtime

py_binary
Exibir origem da regra
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, python_version, restricted_to, srcs_version, stamp, tags, target_compatible_with, testonly, toolchains, visibility)

Um py_binary é um programa Python executável que consiste em uma coleção de arquivos de origem .py (possivelmente pertencendo a outras regras py_library), uma árvore de diretórios *.runfiles contendo todos os códigos e dados necessários para o programa no ambiente de execução e um script stub que inicia o programa com o ambiente e os dados iniciais corretos.

Exemplos

py_binary( name = "foo", srcs = ["foo.py"], data = [":transform"], # a cc_binary which we invoke at run time deps = [ ":foolib", # a py_library ], )

Se você quiser executar um py_binary dentro de outro binário ou teste (por exemplo, executar um binário Python para configurar algum recurso simulado em um java_test), a abordagem correta é fazer com que o outro binário ou teste dependa do py_binary na seção de dados. O outro binário pode localizar o py_binary em relação ao diretório de origem.

py_binary( name = "test_main", srcs = ["test_main.py"], deps = [":testing"], ) java_library( name = "testing", srcs = glob(["*.java"]), data = [":test_main"] )

Argumentos

Atributos

name
Nome, obrigatório

Um nome exclusivo para o destino.

Se main não for especificado, deverá ser igual ao nome do arquivo de origem que é o ponto de entrada principal do aplicativo, menos a extensão. Por exemplo, se o ponto de entrada for chamado de main.py, seu nome precisará ser main.

deps
Lista de rótulos. O padrão é [].
A lista de outras bibliotecas a serem vinculadas ao destino binário. Consulte os comentários gerais sobre deps em Atributos típicos definidos pela maioria das regras de build. Geralmente, são regras py_library.

srcs
Lista de rótulos, obrigatório
A lista de arquivos de origem (.py) que são processados para criar o destino. Isso inclui todo o código de check-in e todos os arquivos de origem gerados. Os destinos de biblioteca pertencem a deps, enquanto outros arquivos binários necessários no momento da execução pertencem a data.

imports
Lista de strings. O padrão é [].
Lista de diretórios de importação a serem adicionados ao PYTHONPATH.
Sujeito à substituição "Make variables". 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 de que esta regra depende. Cada diretório será adicionado a PYTHONPATH pelas regras py_binary que dependem dessa regra.

Caminhos absolutos (que começam com /) e caminhos que fazem referência a um caminho acima da raiz de execução não são permitidos e resultarão em erro.

legacy_create_init
Número inteiro. O padrão é -1.
Define se arquivos __init__.py vazios são implicitamente criados 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 todos os diretórios pais desses diretórios, exceto o diretório raiz do repo. O padrão "auto" 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 ao srcs de destinos Python conforme necessário.

main
Rótulo; o padrão é None
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 será usado (veja acima). Se name não corresponder a nenhum nome de arquivo em srcs, será necessário especificar main.

python_version
String; não configurável; o padrão é "_INTERNAL_SENTINEL"
Define se esse destino (e o deps transitivo) dele será criado para Python 2 ou Python 3. Os valores válidos são "PY2" e "PY3" (o padrão).
A versão do Python é sempre redefinida (possivelmente por padrão) para qualquer versão especificada por esse atributo, independentemente da versão especificada na linha de comando ou por outros destinos superiores que dependam dessa.
Para select() na versão atual do Python, inspecione o valor de @rules_python//python:python_version. Consulte este link para mais informações.
Aviso de bug:esse atributo define a versão em que o Bazel cria o destino. No entanto, devido ao #4815 (link em inglês), o script de stub resultante ainda pode invocar a versão errada do intérprete durante a execução. Consulte esta solução alternativa, que envolve definir um destino py_runtime que aponta para qualquer versão do Python conforme necessário e ativar esse py_runtime definindo --python_top.

srcs_version
String. O padrão é "PY2AND3".
Esse atributo declara o srcs do destino compatível com Python 2, Python 3 ou ambos. Para definir a versão do ambiente de execução do Python, use o atributo python_version de uma regra executável do Python (py_binary ou py_test).
Os valores permitidos são: "PY2AND3", "PY2" e "PY3". Os valores "PY2ONLY" e "PY3ONLY" também são permitidos por motivos históricos, mas são essencialmente os mesmos que "PY2" e "PY3" e precisam ser evitados.
Observe que apenas as regras executáveis (py_binary e py_library) realmente verificam a versão atual do Python em relação ao valor desse atributo. Esse é um recurso. Como py_library não altera a versão atual do Python, se tivesse feito a validação, seria impossível criar as bibliotecas PY2ONLY e PY3ONLY na mesma invocação. Além disso, se houver uma incompatibilidade de versão, o erro só será relatado na fase de execução. Em particular, o erro não aparecerá em uma invocação bazel build --nobuild.
Para receber informações de diagnóstico sobre quais dependências introduzem requisitos de versão, execute o aspecto find_requirements no destino:
bazel build <your target> \ --aspects=@rules_python//python:defs.bzl%find_requirements \ --output_groups=pyversioninfo
Isso vai criar um arquivo com o sufixo -pyversioninfo.txt fornecendo informações sobre por que o destino exige uma ou outra versão do Python. Observe que ele funciona mesmo se o destino especificado não for criado devido a um conflito de versões.

stamp
Número inteiro. O padrão é -1.
Define se as informações da versão serão codificadas no binário. Valores possíveis:

stamp = 1: sempre inclui as informações do build no binário, mesmo em builds --nostamp. Evite essa configuração, já que ela possivelmente elimina o armazenamento em cache remoto do binário e qualquer ação downstream que dependa dele.

stamp = 0: sempre substitui as informações do build por valores constantes. Isso fornece 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 carimbos não são recriados, a menos que as dependências deles mudem.

py_library
Exibir origem da regra
py_library(name, deps, srcs, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, features, imports, licenses, restricted_to, srcs_version, tags, target_compatible_with, testonly, visibility)

Argumentos

Atributos

name
Nome, obrigatório

Um nome exclusivo para o destino.

deps
Lista de rótulos. O padrão é [].
A lista de outras bibliotecas a serem vinculadas ao destino binário. Consulte os comentários gerais sobre deps em Atributos típicos definidos pela maioria das regras de build. Geralmente, são regras py_library.

srcs
Lista de rótulos. O padrão é [].
A lista de arquivos de origem (.py) que são processados para criar o destino. Isso inclui todo o código de check-in e todos os arquivos de origem gerados.

imports
Lista de strings. O padrão é [].
Lista de diretórios de importação a serem adicionados ao PYTHONPATH.
Sujeito à substituição "Make variables". 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 de que esta regra depende. Cada diretório será adicionado a PYTHONPATH pelas regras py_binary que dependem dessa regra.

Caminhos absolutos (que começam com /) e caminhos que fazem referência a um caminho acima da raiz de execução não são permitidos e resultarão em erro.

srcs_version
String. O padrão é "PY2AND3".
Esse atributo declara o srcs do destino compatível com Python 2, Python 3 ou ambos. Para definir a versão do ambiente de execução do Python, use o atributo python_version de uma regra executável do Python (py_binary ou py_test).
Os valores permitidos são: "PY2AND3", "PY2" e "PY3". Os valores "PY2ONLY" e "PY3ONLY" também são permitidos por motivos históricos, mas são essencialmente os mesmos que "PY2" e "PY3" e precisam ser evitados.
Observe que apenas as regras executáveis (py_binary e py_library) realmente verificam a versão atual do Python em relação ao valor desse atributo. Esse é um recurso. Como py_library não altera a versão atual do Python, se tivesse feito a validação, seria impossível criar as bibliotecas PY2ONLY e PY3ONLY na mesma invocação. Além disso, se houver uma incompatibilidade de versão, o erro só será relatado na fase de execução. Em particular, o erro não aparecerá em uma invocação bazel build --nobuild.
Para receber informações de diagnóstico sobre quais dependências introduzem requisitos de versão, execute o aspecto find_requirements no destino:
bazel build <your target> \ --aspects=@rules_python//python:defs.bzl%find_requirements \ --output_groups=pyversioninfo
Isso vai criar um arquivo com o sufixo -pyversioninfo.txt fornecendo informações sobre por que o destino exige uma ou outra versão do Python. Observe que ele funciona mesmo se o destino especificado não for criado devido a um conflito de versões.

py_test
Exibir origem da regra
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, python_version, restricted_to, shard_count, size, srcs_version, stamp, tags, target_compatible_with, testonly, timeout, toolchains, visibility)

Uma regra py_test() compila um teste. Um teste é um wrapper binário em um código de teste.

Exemplos

py_test( name = "runtest_test", srcs = ["runtest_test.py"], deps = [ "//path/to/a/py/library", ], )

Também é possível especificar um módulo principal:

py_test( name = "runtest_test", srcs = [ "runtest_main.py", "runtest_lib.py", ], main = "runtest_main.py", )

Argumentos

Atributos

name
Nome, obrigatório

Um nome exclusivo para o destino.

deps
Lista de rótulos. O padrão é [].
A lista de outras bibliotecas a serem vinculadas ao destino binário. Consulte os comentários gerais sobre deps em Atributos típicos definidos pela maioria das regras de build. Geralmente, são regras py_library.

srcs
Lista de rótulos, obrigatório
A lista de arquivos de origem (.py) que são processados para criar o destino. Isso inclui todo o código de check-in e todos os arquivos de origem gerados. Os destinos de biblioteca pertencem a deps, enquanto outros arquivos binários necessários no momento da execução pertencem a data.

imports
Lista de strings. O padrão é [].
Lista de diretórios de importação a serem adicionados ao PYTHONPATH.
Sujeito à substituição "Make variables". 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 de que esta regra depende. Cada diretório será adicionado a PYTHONPATH pelas regras py_binary que dependem dessa regra.

Caminhos absolutos (que começam com /) e caminhos que fazem referência a um caminho acima da raiz de execução não são permitidos e resultarão em erro.

legacy_create_init
Número inteiro. O padrão é -1.
Define se arquivos __init__.py vazios são implicitamente criados 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 todos os diretórios pais desses diretórios, exceto o diretório raiz do repo. O padrão "auto" 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 ao srcs de destinos Python conforme necessário.

main
Rótulo; o padrão é None
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 será usado (veja acima). Se name não corresponder a nenhum nome de arquivo em srcs, será necessário especificar main.

python_version
String; não configurável; o padrão é "_INTERNAL_SENTINEL"
Define se esse destino (e o deps transitivo) dele será criado para Python 2 ou Python 3. Os valores válidos são "PY2" e "PY3" (o padrão).
A versão do Python é sempre redefinida (possivelmente por padrão) para qualquer versão especificada por esse atributo, independentemente da versão especificada na linha de comando ou por outros destinos superiores que dependam dessa.
Para select() na versão atual do Python, inspecione o valor de @rules_python//python:python_version. Consulte este link para mais informações.
Aviso de bug:esse atributo define a versão em que o Bazel cria o destino. No entanto, devido ao #4815 (link em inglês), o script de stub resultante ainda pode invocar a versão errada do intérprete durante a execução. Consulte esta solução alternativa, que envolve definir um destino py_runtime que aponta para qualquer versão do Python conforme necessário e ativar esse py_runtime definindo --python_top.

srcs_version
String. O padrão é "PY2AND3".
Esse atributo declara o srcs do destino compatível com Python 2, Python 3 ou ambos. Para definir a versão do ambiente de execução do Python, use o atributo python_version de uma regra executável do Python (py_binary ou py_test).
Os valores permitidos são: "PY2AND3", "PY2" e "PY3". Os valores "PY2ONLY" e "PY3ONLY" também são permitidos por motivos históricos, mas são essencialmente os mesmos que "PY2" e "PY3" e precisam ser evitados.
Observe que apenas as regras executáveis (py_binary e py_library) realmente verificam a versão atual do Python em relação ao valor desse atributo. Esse é um recurso. Como py_library não altera a versão atual do Python, se tivesse feito a validação, seria impossível criar as bibliotecas PY2ONLY e PY3ONLY na mesma invocação. Além disso, se houver uma incompatibilidade de versão, o erro só será relatado na fase de execução. Em particular, o erro não aparecerá em uma invocação bazel build --nobuild.
Para receber informações de diagnóstico sobre quais dependências introduzem requisitos de versão, execute o aspecto find_requirements no destino:
bazel build <your target> \ --aspects=@rules_python//python:defs.bzl%find_requirements \ --output_groups=pyversioninfo
Isso vai criar um arquivo com o sufixo -pyversioninfo.txt fornecendo informações sobre por que o destino exige uma ou outra versão do Python. Observe que ele funciona mesmo se o destino especificado não for criado devido a um conflito de versões.

stamp
Número inteiro. O padrão é 0.
Consulte a seção sobre argumentos py_binary(), exceto pelo fato de que o argumento stamp é definido como 0 por padrão para testes.

py_runtime
Exibir origem da regra
py_runtime(name, bootstrap_template, compatible_with, coverage_tool, deprecation, distribs, features, files, interpreter, interpreter_path, licenses, python_version, restricted_to, stub_shebang, tags, target_compatible_with, testonly, visibility)

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 da plataforma ou um ambiente de execução no build. Um ambiente de execução da plataforma acessa um interpretador instalado pelo sistema por um caminho conhecido, enquanto um ambiente de execução no build aponta para um destino executável que atua como intérprete. Nos dois casos, um "intérprete" significa qualquer script de wrapper ou binário executável capaz de executar um script Python transmitido na linha de comando, seguindo as mesmas convenções que o interpretador CPython padrão.
O ambiente de execução da plataforma é, por sua natureza, não hermético. Isso impõe um requisito à plataforma de destino ter um intérprete localizado em um caminho específico. Um ambiente de execução no build pode ou não ser hermético, dependendo se ele aponta para um intérprete registrado ou um script de wrapper que acessa o intérprete do sistema.
Exemplo:

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 o destino.

bootstrap_template
Rótulo; o padrão é "@bazel_tools//tools/python:python_bootstrap_template.txt"
Anteriormente conhecido como "script de stub do Python", esse é o ponto de entrada para todos os destinos executáveis do Python.

coverage_tool
Rótulo; o padrão é None
Esse é um destino usado para coletar informações de cobertura de código dos destinos py_binary e 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 da ferramenta de cobertura do Python. O destino e os arquivos de execução dele serão adicionados aos arquivos de execução quando a cobertura estiver ativada.

O ponto de entrada da ferramenta precisa 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, 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 ambiente de execução. Para um ambiente de execução de plataforma, esse atributo não pode ser definido.

interpreter
Rótulo; o padrão é None
Para um ambiente de execução no build, esse é o destino a ser invocado como intérprete. Para um ambiente de execução de plataforma, 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 de Python na plataforma de destino. Para um tempo de execução no build, esse atributo não pode ser definido.

python_version
String. O padrão é "_INTERNAL_SENTINEL".
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 --incompatible_py3_is_default. No entanto, esse atributo será obrigatório no futuro e não terá valor padrão.

stub_shebang
String. O padrão é "#!/usr/bin/env python3".
Expressão "Shebang" anexada ao script Python de inicialização usado ao executar destinos py_binary.
Consulte o problema 8685 (link em inglês) para motivação.
Não se aplica ao Windows.

Atributos
`name`	Nome, obrigatório Um nome exclusivo para o destino. Se `main` não for especificado, deverá ser igual ao nome do arquivo de origem que é o ponto de entrada principal do aplicativo, menos a extensão. Por exemplo, se o ponto de entrada for chamado de `main.py`, seu nome precisará ser `main`.
`deps`	Lista de rótulos. O padrão é `[]`. A lista de outras bibliotecas a serem vinculadas ao destino binário. Consulte os comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build. Geralmente, são regras `py_library`.
`srcs`	Lista de rótulos, obrigatório A lista de arquivos de origem (`.py`) que são processados para criar o destino. Isso inclui todo o código de check-in e todos os arquivos de origem gerados. Os destinos de biblioteca pertencem a `deps`, enquanto outros arquivos binários necessários no momento da execução pertencem a `data`.
`imports`	Lista de strings. O padrão é `[]`. Lista de diretórios de importação a serem adicionados ao `PYTHONPATH`. Sujeito à substituição "Make variables". 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 de que esta regra depende. Cada diretório será adicionado a `PYTHONPATH` pelas regras `py_binary` que dependem dessa regra. Caminhos absolutos (que começam com `/`) e caminhos que fazem referência a um caminho acima da raiz de execução não são permitidos e resultarão em erro.
`legacy_create_init`	Número inteiro. O padrão é `-1`. Define se arquivos __init__.py vazios são implicitamente criados 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 todos os diretórios pais desses diretórios, exceto o diretório raiz do repo. O padrão "auto" 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 ao `srcs` de destinos Python conforme necessário.
`main`	Rótulo; o padrão é `None` 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` será usado (veja acima). Se `name` não corresponder a nenhum nome de arquivo em `srcs`, será necessário especificar `main`.
`python_version`	String; não configurável; o padrão é `"_INTERNAL_SENTINEL"` Define se esse destino (e o `deps` transitivo) dele será criado para Python 2 ou Python 3. Os valores válidos são `"PY2"` e `"PY3"` (o padrão). A versão do Python é sempre redefinida (possivelmente por padrão) para qualquer versão especificada por esse atributo, independentemente da versão especificada na linha de comando ou por outros destinos superiores que dependam dessa. Para `select()` na versão atual do Python, inspecione o valor de `@rules_python//python:python_version`. Consulte este link para mais informações. Aviso de bug:esse atributo define a versão em que o Bazel cria o destino. No entanto, devido ao #4815 (link em inglês), o script de stub resultante ainda pode invocar a versão errada do intérprete durante a execução. Consulte esta solução alternativa, que envolve definir um destino `py_runtime` que aponta para qualquer versão do Python conforme necessário e ativar esse `py_runtime` definindo `--python_top`.
`srcs_version`	String. O padrão é `"PY2AND3"`. Esse atributo declara o `srcs` do destino compatível com Python 2, Python 3 ou ambos. Para definir a versão do ambiente de execução do Python, use o atributo `python_version` de uma regra executável do Python (`py_binary` ou `py_test`). Os valores permitidos são: `"PY2AND3"`, `"PY2"` e `"PY3"`. Os valores `"PY2ONLY"` e `"PY3ONLY"` também são permitidos por motivos históricos, mas são essencialmente os mesmos que `"PY2"` e `"PY3"` e precisam ser evitados. Observe que apenas as regras executáveis (`py_binary` e `py_library`) realmente verificam a versão atual do Python em relação ao valor desse atributo. Esse é um recurso. Como `py_library` não altera a versão atual do Python, se tivesse feito a validação, seria impossível criar as bibliotecas `PY2ONLY` e `PY3ONLY` na mesma invocação. Além disso, se houver uma incompatibilidade de versão, o erro só será relatado na fase de execução. Em particular, o erro não aparecerá em uma invocação `bazel build --nobuild`. Para receber informações de diagnóstico sobre quais dependências introduzem requisitos de versão, execute o aspecto `find_requirements` no destino: bazel build <your target> \ --aspects=@rules_python//python:defs.bzl%find_requirements \ --output_groups=pyversioninfo Isso vai criar um arquivo com o sufixo `-pyversioninfo.txt` fornecendo informações sobre por que o destino exige uma ou outra versão do Python. Observe que ele funciona mesmo se o destino especificado não for criado devido a um conflito de versões.
`stamp`	Número inteiro. O padrão é `-1`. Define se as informações da versão serão codificadas no binário. Valores possíveis: `stamp = 1`: sempre inclui as informações do build no binário, mesmo em builds `--nostamp`. Evite essa configuração, já que ela possivelmente elimina o armazenamento em cache remoto do binário e qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitui as informações do build por valores constantes. Isso fornece 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 carimbos não são recriados, a menos que as dependências deles mudem.

Atributos
`name`	Nome, obrigatório Um nome exclusivo para o destino.
`bootstrap_template`	Rótulo; o padrão é `"@bazel_tools//tools/python:python_bootstrap_template.txt"` Anteriormente conhecido como "script de stub do Python", esse é o ponto de entrada para todos os destinos executáveis do Python.
`coverage_tool`	Rótulo; o padrão é `None` Esse é um destino usado para coletar informações de cobertura de código dos destinos `py_binary` e `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 da ferramenta de cobertura do Python. O destino e os arquivos de execução dele serão adicionados aos arquivos de execução quando a cobertura estiver ativada. O ponto de entrada da ferramenta precisa 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, 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 ambiente de execução. Para um ambiente de execução de plataforma, esse atributo não pode ser definido.
`interpreter`	Rótulo; o padrão é `None` Para um ambiente de execução no build, esse é o destino a ser invocado como intérprete. Para um ambiente de execução de plataforma, 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 de Python na plataforma de destino. Para um tempo de execução no build, esse atributo não pode ser definido.
`python_version`	String. O padrão é `"_INTERNAL_SENTINEL"`. 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 `--incompatible_py3_is_default`. No entanto, esse atributo será obrigatório no futuro e não terá valor padrão.
`stub_shebang`	String. O padrão é `"#!/usr/bin/env python3"`. Expressão "Shebang" anexada ao script Python de inicialização usado ao executar destinos `py_binary`. Consulte o problema 8685 (link em inglês) para motivação. Não se aplica ao Windows.