Regras
py_binary
Exibir 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 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 essa segmentação. Se main não for especificado, ele será o mesmo que o 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 é deps em
Atributos típicos definidos pela maioria das regras de build.
Elas são geralmente
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 da biblioteca
pertencem a deps , enquanto outros arquivos binários necessários no momento de execução pertencem a
data .
|
imports
|
Lista de strings. O padrão é PYTHONPATH .
Sujeito à substituição de "Make variable". Esses diretórios de importação serão adicionados a essa regra e a todas as regras que dependem dela (não as regras que dependem dessa regra). 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 seja usado. Se for falso, o usuário será
responsável por criar arquivos __init__.py (possivelmente vazios) e adicioná-los a
srcs de destinos Python conforme necessário.
|
main
|
Rótulo; o padrão é srcs . Se não for especificado,
name será usado (consulte acima). Se name não corresponder a nenhum nome de arquivo em srcs , main precisará ser especificado.
|
python_version
|
String; não configurável; 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 qualquer versão especificada por esse atributo, independentemente da versão especificada na linha de comando ou por outros destinos superiores que dependam dela. Se você quiser 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 |
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 atributo python_version de uma regra executável do Python (py_binary ou py_test ).
Os valores permitidos são: Somente as regras executáveis ( Para receber informações de diagnóstico sobre quais dependências introduzem requisitos de versão,
execute o aspecto bazel build <your target> \ --aspects=@rules_python//python:defs.bzl%find_requirements \ --output_groups=pyversioninfo -pyversioninfo.txt , que vai fornecer informações
sobre por que o destino exige uma versão do Python ou outra. Observe que ele funciona mesmo se
o destino especificado não for criado devido a um conflito de versões.
|
stamp
|
Inteiro; padrão é
Os binários carimbados não são reconstruídos, a menos que as dependências mudem. |
py_library
Exibir 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 essa segmentação. |
deps
|
Lista de rótulos; o padrão é deps em
Atributos típicos definidos pela maioria das regras de build.
Elas são geralmente
regras 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". 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
Caminhos absolutos (que começam com |
srcs_version
|
String. O padrão é srcs do destino é 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 Python executável (py_binary ou py_test ).
Os valores permitidos são Somente as regras executáveis ( Para ter informações de diagnóstico sobre quais dependências introduzem requisitos de versão,
execute 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 versão do Python ou outra. Ele funciona mesmo se
a criação do destino falhar devido a um conflito de versão.
|
py_test
Acessar a 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
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 essa segmentação. |
deps
|
Lista de rótulos. O padrão é deps em
Atributos típicos definidos pela maioria das regras de build.
Elas são geralmente
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 é PYTHONPATH .
Sujeito à substituição "Make variables". Esses diretórios de importação serão adicionados a essa regra e a todas as regras que dependem dela (não as regras que dependem dessa regra). 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 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 é 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; não configurável; 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 qualquer versão especificada por esse atributo, independentemente da versão especificada na linha de comando ou por outros destinos superiores que dependam dela. Para 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 |
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 atributo
python_version de uma
regra Python executável (py_binary ou py_test ).
Os valores permitidos são Somente as regras executáveis ( Para ter informações de diagnóstico sobre quais dependências introduzem requisitos de versão,
execute 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 versão do Python ou outra. Ele funciona mesmo se
a criação do destino falhar devido a um conflito de versão.
|
stamp
|
Número inteiro. O padrão é |
py_runtime
Exibir 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. 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. Em
ambos os casos, um "intérprete" significa qualquer script binário executável ou wrapper capaz de
executar um script Python transmitido na linha de comando, seguindo as mesmas convenções do interpretador
CPython padrão.
O ambiente de execução da plataforma é, por sua natureza, não hermético. Ele impõe um requisito à plataforma de destino para 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 essa segmentação. |
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 o executável, se o destino for executável, determina o ponto de entrada da ferramenta de cobertura do Python. O destino e os runfiles serão adicionados aos runfiles quando a cobertura for ativada. O ponto de entrada da ferramenta precisa ser carregável por um intérprete de Python (por exemplo, um
arquivo |
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 flag |
stub_shebang
|
String; o padrão é py_binary .
Consulte o problema 8685 para saber mais. Não se aplica ao Windows. |