Para conferir a documentação da versão estável, use o menu suspenso "Documentos com controle de versão". A visualização padrão reflete a versão mais recente em HEAD.

Esta página foi traduzida pela API Cloud Translation.

Regras do Python

Informar um problema Ver código-fonte

Regras

py_binary
py_library
py_test
py_runtime

bin_py

Ver 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 pertencentes a outras regras de py_library), uma árvore de diretórios *.runfiles contendo todo o código e os dados necessários para o programa no ambiente de execução e um script de 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 de dentro de outro binário ou teste (por exemplo, executar um binário do Python para configurar um recurso simulado em um java_test), a abordagem correta vai ser 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 relativo 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`	`Name; required` Um nome exclusivo para esse destino. Se `main` não for especificado, precisará ser o mesmo do nome do arquivo de origem que é o principal ponto de entrada do aplicativo, menos a extensão. Por exemplo, se o ponto de entrada for chamado de `main.py`, o nome precisará ser `main`.
`deps`	`List of labels; optional` A lista de outras bibliotecas que serão vinculadas ao destino binário. Veja comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build. Geralmente, são regras `py_library`.
`srcs`	`List of labels; required` A lista de arquivos de origem (`.py`) que são processados para criar o destino. Isso inclui todo o código registrado e todos os arquivos de origem gerados. Os destinos da biblioteca pertencem a `deps`, enquanto outros arquivos binários necessários no ambiente de execução pertencem a `data`.
`imports`	`List of strings; optional` Lista de diretórios de importação a serem adicionados ao `PYTHONPATH`. Sujeito à substituição de Tornar variável. Esses diretórios de importação serão adicionados a esta regra e a todas as regras que dependem dela. Observação: não são as regras de que esta regra depende. Cada diretório será adicionado ao `PYTHONPATH` por regras `py_binary` que dependem dessa regra. Caminhos absolutos (caminhos 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`	`Integer; optional; default is -1` Define se é necessário criar implicitamente arquivos __init__.py vazios na árvore runfiles. Eles são criados em todos os diretórios que contêm código-fonte ou bibliotecas compartilhadas do Python e em cada diretório pai desses diretórios, exceto o diretório raiz do repositório. O padrão, "auto", significa "verdadeiro", 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 do Python, conforme necessário.
`main`	`Label; optional` O nome do arquivo de origem que é o principal ponto de entrada do aplicativo. Este 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`, `main` precisará ser especificado.
`python_version`	`String; optional; nonconfigurable; default is "_INTERNAL_SENTINEL"` Define se é necessário criar esse destino (e a `deps` transitiva dele) para o Python 2 ou 3. Os valores válidos são `"PY2"` e `"PY3"` (padrão). A versão do Python é sempre redefinida (possivelmente por padrão) para a versão especificada por esse atributo, independentemente da versão especificada na linha de comando ou por outros destinos maiores que dependem dela. Se você quiser `select()` na versão atual do Python, inspecione o valor de `@rules_python//python:python_version`. Veja mais informações aqui. Aviso de bug: esse atributo define a versão em que o Bazel cria o destino. Porém, devido ao #4815, o script de stub resultante ainda pode invocar a versão errada do intérprete no momento da 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; optional; default is "PY2AND3"` Esse atributo declara o `srcs` do destino como compatível com o Python 2, o 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 (`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 basicamente os mesmos que `"PY2"` e `"PY3"` e precisam ser evitados. Apenas as regras executáveis (`py_binary` e `py_library`) verificam a versão atual do Python em relação ao valor desse atributo. Esse é um recurso. Como `py_library` não muda a versão atual do Python, se ele fizesse 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á informado na fase de execução. Mais especificamente, o erro não vai aparecer em uma invocação `bazel build --nobuild`. Para ver informações de diagnóstico sobre quais dependências apresentam 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 criará um arquivo com o sufixo `-pyversioninfo.txt` fornecendo informações sobre por que o destino exige uma versão do Python ou outra. Isso funciona mesmo que o destino fornecido não seja criado devido a um conflito de versão.
`stamp`	`Integer; optional; default is -1` Define se as informações de compilação serão codificadas no binário. Valores possíveis: `stamp = 1`: sempre cole as informações do build no binário, mesmo em builds do `--nostamp`. Essa configuração precisa ser evitada, já que ela pode eliminar o armazenamento em cache remoto para o binário e todas as ações downstream que dependem dele. `stamp = 0`: sempre substitua informações de build por valores constantes. Isso oferece um bom armazenamento em cache dos resultados da versão. `stamp = -1`: a incorporação de informações de build é controlada pela sinalização `--[no]stamp`. Os binários carimbados não são recriados, a menos que as dependências deles sejam alteradas.

biblioteca py

Ver 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`	`Name; required` Um nome exclusivo para esse destino.
`deps`	`List of labels; optional` A lista de outras bibliotecas que serão vinculadas ao destino binário. Veja comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build. Geralmente, são regras `py_library`.
`srcs`	`List of labels; optional` A lista de arquivos de origem (`.py`) que são processados para criar o destino. Isso inclui todo o código registrado e todos os arquivos de origem gerados.
`imports`	`List of strings; optional` Lista de diretórios de importação a serem adicionados ao `PYTHONPATH`. Sujeito à substituição de Tornar variável. Esses diretórios de importação serão adicionados a esta regra e a todas as regras que dependem dela. Observação: não são as regras de que esta regra depende. Cada diretório será adicionado ao `PYTHONPATH` por regras `py_binary` que dependem dessa regra. Caminhos absolutos (caminhos 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; optional; default is "PY2AND3"` Esse atributo declara o `srcs` do destino como compatível com o Python 2, o 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 (`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 basicamente os mesmos que `"PY2"` e `"PY3"` e precisam ser evitados. Apenas as regras executáveis (`py_binary` e `py_library`) verificam a versão atual do Python em relação ao valor desse atributo. Esse é um recurso. Como `py_library` não muda a versão atual do Python, se ele fizesse 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á informado na fase de execução. Mais especificamente, o erro não vai aparecer em uma invocação `bazel build --nobuild`. Para ver informações de diagnóstico sobre quais dependências apresentam 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 criará um arquivo com o sufixo `-pyversioninfo.txt` fornecendo informações sobre por que o destino exige uma versão do Python ou outra. Isso funciona mesmo que o destino fornecido não seja criado devido a um conflito de versão.

teste_py

Ver 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 torno de um código.

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`	`Name; required` Um nome exclusivo para esse destino.
`deps`	`List of labels; optional` A lista de outras bibliotecas que serão vinculadas ao destino binário. Veja comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build. Geralmente, são regras `py_library`.
`srcs`	`List of labels; required` A lista de arquivos de origem (`.py`) que são processados para criar o destino. Isso inclui todo o código registrado e todos os arquivos de origem gerados. Os destinos da biblioteca pertencem a `deps`, enquanto outros arquivos binários necessários no ambiente de execução pertencem a `data`.
`imports`	`List of strings; optional` Lista de diretórios de importação a serem adicionados ao `PYTHONPATH`. Sujeito à substituição de Tornar variável. Esses diretórios de importação serão adicionados a esta regra e a todas as regras que dependem dela. Observação: não são as regras de que esta regra depende. Cada diretório será adicionado ao `PYTHONPATH` por regras `py_binary` que dependem dessa regra. Caminhos absolutos (caminhos 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`	`Integer; optional; default is -1` Define se é necessário criar implicitamente arquivos __init__.py vazios na árvore runfiles. Eles são criados em todos os diretórios que contêm código-fonte ou bibliotecas compartilhadas do Python e em cada diretório pai desses diretórios, exceto o diretório raiz do repositório. O padrão, "auto", significa "verdadeiro", 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 do Python, conforme necessário.
`main`	`Label; optional` O nome do arquivo de origem que é o principal ponto de entrada do aplicativo. Este 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`, `main` precisará ser especificado.
`python_version`	`String; optional; nonconfigurable; default is "_INTERNAL_SENTINEL"` Define se é necessário criar esse destino (e a `deps` transitiva dele) para o Python 2 ou 3. Os valores válidos são `"PY2"` e `"PY3"` (padrão). A versão do Python é sempre redefinida (possivelmente por padrão) para a versão especificada por esse atributo, independentemente da versão especificada na linha de comando ou por outros destinos maiores que dependem dela. Se você quiser `select()` na versão atual do Python, inspecione o valor de `@rules_python//python:python_version`. Veja mais informações aqui. Aviso de bug: esse atributo define a versão em que o Bazel cria o destino. Porém, devido ao #4815, o script de stub resultante ainda pode invocar a versão errada do intérprete no momento da 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; optional; default is "PY2AND3"` Esse atributo declara o `srcs` do destino como compatível com o Python 2, o 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 (`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 basicamente os mesmos que `"PY2"` e `"PY3"` e precisam ser evitados. Apenas as regras executáveis (`py_binary` e `py_library`) verificam a versão atual do Python em relação ao valor desse atributo. Esse é um recurso. Como `py_library` não muda a versão atual do Python, se ele fizesse 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á informado na fase de execução. Mais especificamente, o erro não vai aparecer em uma invocação `bazel build --nobuild`. Para ver informações de diagnóstico sobre quais dependências apresentam 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 criará um arquivo com o sufixo `-pyversioninfo.txt` fornecendo informações sobre por que o destino exige uma versão do Python ou outra. Isso funciona mesmo que o destino fornecido não seja criado devido a um conflito de versão.
`stamp`	`Integer; optional; default is 0` Consulte a seção sobre argumentos py_binary(), exceto que o argumento do carimbo está definido como 0 por padrão para testes.

py_tempo de execução

Ver 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.

Um destino py_runtime pode representar um ambiente de execução da plataforma ou um ambiente de execução in-build. Um ambiente de execução da plataforma acessa um interpretador instalado pelo sistema em um caminho conhecido, enquanto um ambiente de execução em compilação aponta para um destino executável que atua como interpretador. Em ambos os casos, um "intérprete" significa qualquer script binário ou wrapper executável 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 é, por sua natureza, não hermético. Aplica um requisito na plataforma de destino a um intérprete localizado em um caminho específico. Um ambiente de execução in-build pode ou não ser hermético, dependendo se ele aponta para um interpretador 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`	`Name; required` Um nome exclusivo para esse destino.
`bootstrap_template`	`Label; optional; default is @bazel_tools//tools/python:python_bootstrap_template.txt` Antes chamado de "script de stub Python", ele é o ponto de entrada de cada destino executável em Python.
`coverage_tool`	`Label; optional` Esse é um destino a ser usado para coletar informações de cobertura de código dos destinos `py_binary` e `py_test`. Se definido, o destino precisará produzir um único arquivo ou ser e 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 runfiles serão adicionados aos runfiles quando a cobertura estiver 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 e incluir, pelo menos, os subcomandos `run` e `lcov`.
`files`	`List of labels; optional` Para um ambiente de execução no build, esse é o conjunto de arquivos que compõem o ambiente de execução. Esses arquivos serão adicionados aos runfiles de binários do Python que usam esse ambiente de execução. Para um ambiente de execução da plataforma, esse atributo não pode ser definido.
`interpreter`	`Label; optional` Para um ambiente de execução in-build, esse é o destino a ser invocado como intérprete. Para um ambiente de execução da plataforma, esse atributo não pode ser definido.
`interpreter_path`	`String; optional` Para um ambiente de execução da plataforma, esse é o caminho absoluto de um interpretador do Python na plataforma de destino. Para um ambiente de execução no build, esse atributo não pode ser definido.
`python_version`	`String; optional; default is "_INTERNAL_SENTINEL"` Se esse ambiente de execução é para o Python versão 2 ou 3. Os valores válidos são `"PY2"` e `"PY3"`. O valor padrão é controlado pela sinalização `--incompatible_py3_is_default`. No entanto, no futuro esse atributo será obrigatório e não terá valor padrão.
`stub_shebang`	`String; optional; default is "#!/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 ver a motivação. Não se aplica ao Windows.