Regras do Python

Informar um problema Conferir origem Noite · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

Regras

py_binary
py_library
py_test
py_runtime

py_binary

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 de uma coleção de arquivos de origem .py (possivelmente pertencendo a outras regras py_library), um *.runfiles árvore de diretórios contendo todos os códigos e dados necessários para o programa em ambiente de execução e um script stub que inicia o programa com o ambiente inicial e os dados 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 (por exemplo, executar um binário Python para configurar um recurso simulado em um java_test), a abordagem correta é tornar o outro binário ou dependem do py_binary na seção de dados. O outro o binário pode localizar o py_binary em relação à origem diretório.

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, terá que 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 `main.py`, seu nome será `main`.
`deps`	Lista de rótulos o padrão é `[]` A lista de outras bibliotecas a serem vinculadas ao destino binário. Veja os comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build. Elas geralmente são `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. Destinos da biblioteca pertencem a `deps`, enquanto outros arquivos binários necessários no tempo de 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". Essas importações diretórios serão adicionados para esta regra e todas as regras que dependem dela (observação: não os de que esta regra depende. Cada diretório será adicionado a `PYTHONPATH` pelo `py_binary` que dependem dela. 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 permitidas 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 pai desses diretórios, exceto a raiz do repositório diretório. O padrão, "auto", significa "true", a menos que `--incompatible_default_to_explicit_init_py` é 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, Em vez disso, `name` será usado (veja acima). Se `name` não corresponder a qualquer nome de arquivo em `srcs`, `main` precisa ser especificado.
`python_version`	String; nonconfigurable; 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 a versão especificada por este atributo, independentemente da versão especificada na linha de comando ou pelo ou outras metas mais altas que dependam deste. Para `select()` na versão atual do Python, inspecione o de `@rules_python//python:python_version`. Consulte aqui para mais informações. Aviso de bug:esse atributo define a versão em que o Bazel compila o destino. mas devido à #4815, a o script de stub resultante ainda poderá invocar a versão errada do intérprete no ambiente de execução. Consulte este alternativa, que envolve a definição de um destino `py_runtime` que aponta para a versão do Python conforme necessário e ativar `py_runtime` definindo `--python_top`.
`srcs_version`	String; o padrão é `"PY2AND3"` Esse atributo declara a `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 O atributo `python_version` de um 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 para dados históricos mas são basicamente os mesmos que `"PY2"` e `"PY3"` e deve ser evitada. 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. Este é um recurso, já que `py_library` não altera o Python atual se ela tivesse realizado a validação, seria impossível criar ambas `PY2ONLY` e `PY3ONLY` na mesma invocação.) Além disso, se houver um incompatibilidade de versão, o erro só é relatado na fase de execução. Especificamente, o não aparecerá em uma invocação `bazel build --nobuild`. Para ter informações de diagnóstico sobre quais dependências introduzem requisitos de versão, é possível executar 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 a criação do destino especificado falhou 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 inclua as informações do build no binário, mesmo em `--nostamp` builds. Este deve ser evitada, já que ela pode eliminar o armazenamento em cache remoto dos binário e qualquer ação downstream que dependa dele. `stamp = 0`: sempre substitui as informações do build por valores constantes. Isso oferece um bom armazenamento em cache dos resultados da compilação. `stamp = -1`: a incorporação de informações do build é controlada pelo sinalização `--[no]stamp`. Os binários carimbos não são recriados, a menos que as dependências deles mudem.

py_library

Conferir 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. Veja os comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build. Elas geralmente são `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". Essas importações diretórios serão adicionados para esta regra e todas as regras que dependem dela (observação: não os de que esta regra depende. Cada diretório será adicionado a `PYTHONPATH` pelo `py_binary` que dependem dela. 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 permitidas e resultarão em erro.
`srcs_version`	String; o padrão é `"PY2AND3"` Esse atributo declara a `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 O atributo `python_version` de um 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 para dados históricos mas são basicamente os mesmos que `"PY2"` e `"PY3"` e deve ser evitada. 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. Este é um recurso, já que `py_library` não altera o Python atual se ela tivesse realizado a validação, seria impossível criar ambas `PY2ONLY` e `PY3ONLY` na mesma invocação.) Além disso, se houver um incompatibilidade de versão, o erro só é relatado na fase de execução. Especificamente, o não aparecerá em uma invocação `bazel build --nobuild`. Para ter informações de diagnóstico sobre quais dependências introduzem requisitos de versão, é possível executar 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 a criação do destino especificado falhou devido a um conflito de versões.

py_test

Conferir 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 com códigos 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. Veja os comentários gerais sobre `deps` em Atributos típicos definidos pela maioria das regras de build. Elas geralmente são `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. Destinos da biblioteca pertencem a `deps`, enquanto outros arquivos binários necessários no tempo de 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". Essas importações diretórios serão adicionados para esta regra e todas as regras que dependem dela (observação: não os de que esta regra depende. Cada diretório será adicionado a `PYTHONPATH` pelo `py_binary` que dependem dela. 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 permitidas 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 pai desses diretórios, exceto a raiz do repositório diretório. O padrão, "auto", significa "true", a menos que `--incompatible_default_to_explicit_init_py` é 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, Em vez disso, `name` será usado (veja acima). Se `name` não corresponder a qualquer nome de arquivo em `srcs`, `main` precisa ser especificado.
`python_version`	String; nonconfigurable; 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 a versão especificada por este atributo, independentemente da versão especificada na linha de comando ou pelo ou outras metas mais altas que dependam deste. Para `select()` na versão atual do Python, inspecione o de `@rules_python//python:python_version`. Consulte aqui para mais informações. Aviso de bug:esse atributo define a versão em que o Bazel compila o destino. mas devido à #4815, a o script de stub resultante ainda poderá invocar a versão errada do intérprete no ambiente de execução. Consulte este alternativa, que envolve a definição de um destino `py_runtime` que aponta para a versão do Python conforme necessário e ativar `py_runtime` definindo `--python_top`.
`srcs_version`	String; o padrão é `"PY2AND3"` Esse atributo declara a `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 O atributo `python_version` de um 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 para dados históricos mas são basicamente os mesmos que `"PY2"` e `"PY3"` e deve ser evitada. 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. Este é um recurso, já que `py_library` não altera o Python atual se ela tivesse realizado a validação, seria impossível criar ambas `PY2ONLY` e `PY3ONLY` na mesma invocação.) Além disso, se houver um incompatibilidade de versão, o erro só é relatado na fase de execução. Especificamente, o não aparecerá em uma invocação `bazel build --nobuild`. Para ter informações de diagnóstico sobre quais dependências introduzem requisitos de versão, é possível executar 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 a criação do destino especificado falhou devido a um conflito de versões.
`stamp`	Número inteiro o padrão é `0` Consulte a seção sobre argumentos py_binary(), exceto que o argumento stamp está definido como 0 por padrão para testes.

py_runtime

Conferir 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. O ambiente de execução da plataforma acessa um interpretador instalado pelo sistema em uma enquanto o tempo de execução integrado aponta para um destino executável que atua como intérprete. Em em ambos os casos, um "intérprete" qualquer script de wrapper ou binário executável capaz de executando um script Python transmitido na linha de comando, seguindo as mesmas convenções interpretador do CPython.

O ambiente de execução da plataforma é, por sua natureza, não hermético. Impõe um requisito à plataforma de destino ter um intérprete em um caminho específico. Um tempo de execução no build pode ou não ser hermético, dependendo se ela aponta para um intérprete registrado ou um script de wrapper que acessa o e 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 de entrada para cada destino executável do Python.
`coverage_tool`	Rótulo o padrão é `None` Meta usada para coletar informações de cobertura de código de `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 para o executável, se o destino for executável; determina o ponto de entrada da ferramenta de cobertura do Python. O destino e seu os arquivos de execução serão adicionados a eles quando a cobertura estiver ativada. O ponto de entrada da ferramenta deve ser carregável por um intérprete de Python (por exemplo, um `.py` ou `.pyc`). Ele precisa aceitar os argumentos da 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 ser adicionado 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 deve 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 uma plataforma ambiente de execução, esse atributo não deve ser definido.
`interpreter_path`	String; o padrão é `""` Para um ambiente de execução de plataforma, este é o caminho absoluto de um interpretador Python no destino de plataforma. 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"` "Shebang" expressão anexada ao script de inicialização do Python usada ao executar destinos `py_binary`. Consulte o problema 8685 (link em inglês) e motivação. Não se aplica ao Windows.