Regras do Python

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

Regras

py_binary

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