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 o destino. Se main não for especificado, deverá 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 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.
Geralmente, são 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 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 |
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 , será necessário especificar main .
|
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 dessa. 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 executável do Python (py_binary ou py_test ).
Os valores permitidos são: Observe que apenas 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=pyversioninfoIsso 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
o destino especificado não for criado 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
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 o destino. |
deps
|
Lista de rótulos. O padrão é deps em
Atributos típicos definidos pela maioria das regras de build.
Geralmente, são 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 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: Observe que apenas 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=pyversioninfoIsso 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
o destino especificado não for criado devido a um conflito de versões.
|
py_test
Exibir 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 o destino. |
deps
|
Lista de rótulos. O padrão é deps em
Atributos típicos definidos pela maioria das regras de build.
Geralmente, são 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 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 |
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 , será necessário especificar main .
|
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 dessa. 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 executável do Python (py_binary ou py_test ).
Os valores permitidos são: Observe que apenas 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=pyversioninfoIsso 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
o destino especificado não for criado devido a um conflito de versões.
|
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. Nos
dois casos, um "intérprete" significa qualquer script de wrapper ou binário executável capaz de
executar um script Python transmitido na linha de comando, seguindo as mesmas convenções que o interpretador
CPython padrão.
O ambiente de execução da plataforma é, por sua natureza, não hermético. Isso impõe um requisito à plataforma de destino 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 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 o executável, se o destino for executável, determina o ponto de entrada da ferramenta de cobertura do Python. O destino e os arquivos de execução dele serão adicionados aos arquivos de execução quando a cobertura estiver 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 sinalização |
stub_shebang
|
String. O padrão é py_binary .
Consulte o problema 8685 (link em inglês) para motivação. Não se aplica ao Windows. |