Regras
py_binary
Conferir origem da regrapy_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 é 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 é 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
Caminhos absolutos (que começam com |
legacy_create_init
|
Número inteiro o padrão é --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 é 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 é 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 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 |
srcs_version
|
String; o padrã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
O atributo python_version de um
regra executável do Python (py_binary ou py_test ).
Os valores permitidos são: Observe que apenas as regras executáveis ( Para ter informações de diagnóstico sobre quais dependências introduzem requisitos de versão,
é possível executar o aspecto bazel build <your target> \ --aspects=@rules_python//python:defs.bzl%find_requirements \ --output_groups=pyversioninfo -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 é
Os binários carimbos não são recriados, a menos que as dependências deles mudem. |
py_library
Conferir origem da regrapy_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 é 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 é .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 é 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
Caminhos absolutos (que começam com |
srcs_version
|
String; o padrã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
O atributo python_version de um
regra executável do Python (py_binary ou py_test ).
Os valores permitidos são: Observe que apenas as regras executáveis ( Para ter informações de diagnóstico sobre quais dependências introduzem requisitos de versão,
é possível executar o aspecto bazel build <your target> \ --aspects=@rules_python//python:defs.bzl%find_requirements \ --output_groups=pyversioninfo -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 regrapy_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 é 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 é 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
Caminhos absolutos (que começam com |
legacy_create_init
|
Número inteiro o padrão é --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 é 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 é 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 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 |
srcs_version
|
String; o padrã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
O atributo python_version de um
regra executável do Python (py_binary ou py_test ).
Os valores permitidos são: Observe que apenas as regras executáveis ( Para ter informações de diagnóstico sobre quais dependências introduzem requisitos de versão,
é possível executar o aspecto bazel build <your target> \ --aspects=@rules_python//python:defs.bzl%find_requirements \ --output_groups=pyversioninfo -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 é |
py_runtime
Conferir origem da regrapy_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 é |
coverage_tool
|
Rótulo o padrão é 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
|
files
|
Lista de rótulos o padrão é |
interpreter
|
Rótulo o padrão é |
interpreter_path
|
String; o padrão é |
python_version
|
String; o padrão é "PY2"
e "PY3" .
O valor padrão é controlado pela sinalização |
stub_shebang
|
String; o padrão é py_binary .
Consulte o problema 8685 (link em inglês) e motivação. Não se aplica ao Windows. |