Python नियम

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

नियम

py_बाइनरी

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)

py_binary एक ऐसा Python प्रोग्राम है जिसमें एक्ज़ीक्यूट किया जा सकता है. इस सोर्स में .py सोर्स फ़ाइलें होती हैं, जो शायद अन्य py_library नियमों से जुड़ी होती हैं. साथ ही, यह एक *.runfiles डायरेक्ट्री ट्री होता है, जिसमें रन टाइम के दौरान ज़रूरी सभी कोड और डेटा की ज़रूरत होती है. साथ ही, एक स्टब स्क्रिप्ट भी होती है, जिसमें सही इन्फ़्रास्ट्रक्चर और डेटा के साथ प्रोग्राम शुरू किया जाता है.

उदाहरण

py_binary(
    name = "foo",
    srcs = ["foo.py"],
    data = [":transform"],  # a cc_binary which we invoke at run time
    deps = [
        ":foolib",  # a py_library
    ],
)

अगर आप किसी अन्य बाइनरी या टेस्ट से py_binary चलाना चाहते हैं (उदाहरण के लिए, java_test में कोई नकली बाइनरी चलाने के लिए) Python का इस्तेमाल करता है, तो सही तरीके से दूसरी बाइनरी या जांच को अपने डेटा सेक्शन में py_binary पर निर्भर करना होगा. इसके बाद, दूसरी बाइनरी सोर्स डायरेक्ट्री से मिलते-जुलते py_binary का पता लगा सकती हैं.

py_binary(
    name = "test_main",
    srcs = ["test_main.py"],
    deps = [":testlib"],
)

java_library(
    name = "testing",
    srcs = glob(["*.java"]),
    data = [":test_main"]
)

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए कोई खास नाम.


अगर main तय नहीं है, तो यह उसी सोर्स फ़ाइल के नाम जैसा होना चाहिए जो ऐप्लिकेशन के मुख्य एंट्री पॉइंट है. इसमें एक्सटेंशन शामिल नहीं होना चाहिए. उदाहरण के लिए, अगर आपके एंट्री पॉइंट को main.py कहा जाता है, तो आपका नाम main होना चाहिए.
deps

List of labels; optional

बाइनरी टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. deps के बारे में सामान्य टिप्पणियां देखें. इसके लिए, बिल्ड के ज़्यादातर नियमों के मुताबिक, सामान्य एट्रिब्यूट पर जाएं. आम तौर पर, ये py_library नियम होते हैं.
srcs

List of labels; required

स्रोत (.py) फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. इसमें, चेक इन किए हुए सभी कोड और जनरेट की गई सोर्स फ़ाइलें शामिल हैं. लाइब्रेरी के टारगेट deps में शामिल हैं, जबकि रनटाइम के दौरान इस्तेमाल की जाने वाली अन्य बाइनरी फ़ाइलें data से जुड़ी होती हैं.
imports

List of strings; optional

PYTHONPATH में जोड़ी जाने वाली इंपोर्ट डायरेक्ट्री की सूची.

"वैरिएबल और कोट बनाएं विकल्प के अधीन. ये इंपोर्ट डायरेक्ट्री, इस नियम और इससे जुड़े सभी नियमों पर लागू होंगी. ध्यान दें: वे नियम जिन पर निर्भर हैं. इस नियम पर निर्भर करने वाले py_binary नियमों से, हर डायरेक्ट्री को PYTHONPATH में जोड़ा जाएगा.

एब्सोल्यूट पाथ और / से शुरू होने वाले पाथ की अनुमति नहीं है. साथ ही, एक्ज़ीक्यूशन रूट के ऊपर किसी पाथ से जुड़े पाथ की वजह से गड़बड़ी हो सकती है.

legacy_create_init

Integer; optional; default is -1

अनजाने में, रन फ़ाइलें ट्री में खाली __init__.py फ़ाइल बनानी है या नहीं. इन्हें Python सोर्स कोड या शेयर की गई लाइब्रेरी वाली हर डायरेक्ट्री में बनाया जाता है. साथ ही, ये डायरेक्ट्री की हर पैरंट डायरेक्ट्री में बनाए जाते हैं. इसमें रेपो रूट डायरेक्ट्री शामिल नहीं होती. डिफ़ॉल्ट, अपने-आप का मतलब है कि जब तक --incompatible_default_to_explicit_init_py का इस्तेमाल नहीं किया जाता, तब तक यह सही है. अगर गलत हो, तो उपयोगकर्ता __init__.py वाली फ़ाइलें बनाने और उन्हें ज़रूरत के मुताबिक srcs के Python टारगेट में जोड़ने के लिए ज़िम्मेदार है.
main

Label; optional

उस सोर्स फ़ाइल का नाम जो ऐप्लिकेशन का मुख्य एंट्री पॉइंट है. यह फ़ाइल srcs में भी शामिल होनी चाहिए. अगर इसे तय नहीं किया गया है, तो इसके बजाय name का इस्तेमाल किया जाता है (ऊपर देखें). अगर name, srcs में मौजूद किसी भी फ़ाइल नाम से मेल नहीं खाता, तो main की जानकारी देना ज़रूरी है.
python_version

String; optional; nonconfigurable; default is "_INTERNAL_SENTINEL"

Python 2 या Python 3 के लिए, यह टारगेट (और इसके ट्रांज़िटिव deps) बनाना है या नहीं. मान्य वैल्यू "PY2" और "PY3" (डिफ़ॉल्ट) हैं.

Python वर्शन हमेशा रीसेट किया जाता है (डिफ़ॉल्ट रूप से) जो इस एट्रिब्यूट में बताए गए किसी भी वर्शन पर लागू होता है. कमांड लाइन पर दिए गए वर्शन या इस बात पर निर्भर अन्य टारगेट टारगेट वर्शन पर ध्यान दिए बिना.

अगर आपको मौजूदा Python वर्शन पर select() करना है, तो @rules_python//python:python_version की वैल्यू की जांच की जा सकती है. ज़्यादा जानकारी के लिए, यहां देखें.

गड़बड़ी की चेतावनी: यह एट्रिब्यूट वह वर्शन सेट करता है जिसके लिए बेज़ल आपका टारगेट बनाता है, लेकिन #4815 की वजह से, स्टब स्क्रिप्ट अब भी रनटाइम पर गलत अनुवादक वर्शन शुरू कर सकती है. यह तरीका देखें. इसमें py_runtime टारगेट के बारे में बताना शामिल है, जो ज़रूरत के हिसाब से Python वर्शन पर ले जाता है. साथ ही, --python_top को सेट करके, इस py_runtime को चालू करें.

srcs_version

String; optional; default is "PY2AND3"

यह एट्रिब्यूट बताता है कि टारगेट srcs का Python 2, Python 3 या दोनों के साथ काम करता है. असल में, Python रनटाइम वर्शन सेट करने के लिए, एक्ज़ीक्यूटेबल Python नियम (py_binary या py_test) का python_version एट्रिब्यूट इस्तेमाल करें.

इसका वैल्यू इस्तेमाल किया जा सकता है: "PY2AND3", "PY2", और "PY3". ऐतिहासिक वजहों से, "PY2ONLY" और "PY3ONLY" की वैल्यू भी दी जा सकती है. हालांकि, ये "PY2" और "PY3" जैसी ही होती हैं. इन्हें इस्तेमाल नहीं किया जाना चाहिए.

ध्यान दें कि सिर्फ़ एक्ज़ीक्यूटेबल नियमों (py_binary और py_library ) के लिए, Python के मौजूदा वर्शन की पुष्टि इस एट्रिब्यूट की वैल्यू से की जाती है. (यह एक सुविधा है; क्योंकि py_library, मौजूदा Python वर्शन में बदलाव नहीं करता है. अगर यह पुष्टि करता है, तो यह एक ही शुरू में PY2ONLY और PY3ONLY लाइब्रेरी, दोनों बनाना मुश्किल होगा.) इसके अलावा, अगर कोई वर्शन मेल नहीं खाता, तो गड़बड़ी को सिर्फ़ एक्ज़ीक्यूशन के दौरान रिपोर्ट किया जाता है. खास तौर पर, यह गड़बड़ी bazel build --nobuild शुरू करने पर नहीं दिखेगी.)

इस बात पर निर्भर करने के लिए कि किस डिपेंडेंसी से वर्शन से जुड़ी ज़रूरी शर्तें लागू होती हैं, अपने टारगेट पर find_requirements का इस्तेमाल किया जा सकता है:

          bazel build <your target> \
              --aspects=@rules_python//python:defs.bzl%find_requirements \
              --output_groups=pyversioninfo
          
इससे, -pyversioninfo.txt के साथ एक फ़ाइल बनेगी. इसमें आपको यह जानकारी दी जाएगी कि आपके टारगेट के लिए एक Python या किसी दूसरे वर्शन की ज़रूरत क्यों है. ध्यान दें कि यह नीति तब भी काम करती है, जब दिया गया वर्शन किसी वर्शन विवाद की वजह से न बना हो.

stamp

Integer; optional; default is -1

क्या बाइनरी में बिल्ड की जानकारी को कोड में बदलना है. जितने तरह के प्लेसमेंट हो सकते हैं उनकी जानकारी यहां दी गई है:
  • stamp = 1: बिल्ड की जानकारी को हमेशा बाइनरी में बनाएं. भले ही, --nostamp बिल्ड में हो. इस सेटिंग से बचा जाना चाहिए, क्योंकि इससे बाइनरी और इस पर निर्भर डाउनस्ट्रीम कार्रवाइयों के लिए, रिमोट कैशिंग की सुविधा बंद हो सकती है.
  • stamp = 0: बिल्ड की जानकारी को हमेशा स्थायी वैल्यू से बदलें. इससे, बिल्ड को अच्छे से कैश मेमोरी में सेव किया जा सकता है.
  • stamp = -1: बिल्ड की जानकारी को एम्बेड करने का काम --[no]stamp फ़्लैग करता है.

स्टैंप वाली बाइनरी को तब तक नहीं बनाया जाता, जब तक उनकी डिपेंडेंसी नहीं बदलती.

py_library

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)

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए कोई खास नाम.

deps

List of labels; optional

बाइनरी टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. deps के बारे में सामान्य टिप्पणियां देखें. इसके लिए, बिल्ड के ज़्यादातर नियमों के मुताबिक, सामान्य एट्रिब्यूट पर जाएं. आम तौर पर, ये py_library नियम होते हैं.
srcs

List of labels; optional

स्रोत (.py) फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. इसमें, चेक इन किए हुए सभी कोड और जनरेट की गई सोर्स फ़ाइलें शामिल हैं.
imports

List of strings; optional

PYTHONPATH में जोड़ी जाने वाली इंपोर्ट डायरेक्ट्री की सूची.

"वैरिएबल और कोट बनाएं विकल्प के अधीन. ये इंपोर्ट डायरेक्ट्री, इस नियम और इससे जुड़े सभी नियमों पर लागू होंगी. ध्यान दें: वे नियम जिन पर निर्भर हैं. इस नियम पर निर्भर करने वाले py_binary नियमों से, हर डायरेक्ट्री को PYTHONPATH में जोड़ा जाएगा.

एब्सोल्यूट पाथ और / से शुरू होने वाले पाथ की अनुमति नहीं है. साथ ही, एक्ज़ीक्यूशन रूट के ऊपर किसी पाथ से जुड़े पाथ की वजह से गड़बड़ी हो सकती है.

srcs_version

String; optional; default is "PY2AND3"

यह एट्रिब्यूट बताता है कि टारगेट srcs का Python 2, Python 3 या दोनों के साथ काम करता है. असल में, Python रनटाइम वर्शन सेट करने के लिए, एक्ज़ीक्यूटेबल Python नियम (py_binary या py_test) का python_version एट्रिब्यूट इस्तेमाल करें.

इसका वैल्यू इस्तेमाल किया जा सकता है: "PY2AND3", "PY2", और "PY3". ऐतिहासिक वजहों से, "PY2ONLY" और "PY3ONLY" की वैल्यू भी दी जा सकती है. हालांकि, ये "PY2" और "PY3" जैसी ही होती हैं. इन्हें इस्तेमाल नहीं किया जाना चाहिए.

ध्यान दें कि सिर्फ़ एक्ज़ीक्यूटेबल नियमों (py_binary और py_library ) के लिए, Python के मौजूदा वर्शन की पुष्टि इस एट्रिब्यूट की वैल्यू से की जाती है. (यह एक सुविधा है; क्योंकि py_library, मौजूदा Python वर्शन में बदलाव नहीं करता है. अगर यह पुष्टि करता है, तो यह एक ही शुरू में PY2ONLY और PY3ONLY लाइब्रेरी, दोनों बनाना मुश्किल होगा.) इसके अलावा, अगर कोई वर्शन मेल नहीं खाता, तो गड़बड़ी को सिर्फ़ एक्ज़ीक्यूशन के दौरान रिपोर्ट किया जाता है. खास तौर पर, यह गड़बड़ी bazel build --nobuild शुरू करने पर नहीं दिखेगी.)

इस बात पर निर्भर करने के लिए कि किस डिपेंडेंसी से वर्शन से जुड़ी ज़रूरी शर्तें लागू होती हैं, अपने टारगेट पर find_requirements का इस्तेमाल किया जा सकता है:

          bazel build <your target> \
              --aspects=@rules_python//python:defs.bzl%find_requirements \
              --output_groups=pyversioninfo
          
इससे, -pyversioninfo.txt के साथ एक फ़ाइल बनेगी. इसमें आपको यह जानकारी दी जाएगी कि आपके टारगेट के लिए एक Python या किसी दूसरे वर्शन की ज़रूरत क्यों है. ध्यान दें कि यह नीति तब भी काम करती है, जब दिया गया वर्शन किसी वर्शन विवाद की वजह से न बना हो.

py_test

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)

py_test() नियम, जांच को कंपाइल करता है. टेस्ट, कुछ टेस्ट कोड के आस-पास मौजूद बाइनरी रैपर होता है.

उदाहरण

py_test(
    name = "runtest_test",
    srcs = ["runtest_test.py"],
    deps = [
        "//path/to/a/py/library",
    ],
)

एक मुख्य मॉड्यूल भी तय किया जा सकता है:

py_test(
    name = "runtest_test",
    srcs = [
        "runtest_main.py",
        "runtest_lib.py",
    ],
    main = "runtest_main.py",
)

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए कोई खास नाम.

deps

List of labels; optional

बाइनरी टारगेट में लिंक की जाने वाली अन्य लाइब्रेरी की सूची. deps के बारे में सामान्य टिप्पणियां देखें. इसके लिए, बिल्ड के ज़्यादातर नियमों के मुताबिक, सामान्य एट्रिब्यूट पर जाएं. आम तौर पर, ये py_library नियम होते हैं.
srcs

List of labels; required

स्रोत (.py) फ़ाइलों की सूची, जिन्हें टारगेट बनाने के लिए प्रोसेस किया जाता है. इसमें, चेक इन किए हुए सभी कोड और जनरेट की गई सोर्स फ़ाइलें शामिल हैं. लाइब्रेरी के टारगेट deps में शामिल हैं, जबकि रनटाइम के दौरान इस्तेमाल की जाने वाली अन्य बाइनरी फ़ाइलें data से जुड़ी होती हैं.
imports

List of strings; optional

PYTHONPATH में जोड़ी जाने वाली इंपोर्ट डायरेक्ट्री की सूची.

"वैरिएबल और कोट बनाएं विकल्प के अधीन. ये इंपोर्ट डायरेक्ट्री, इस नियम और इससे जुड़े सभी नियमों पर लागू होंगी. ध्यान दें: वे नियम जिन पर निर्भर हैं. इस नियम पर निर्भर करने वाले py_binary नियमों से, हर डायरेक्ट्री को PYTHONPATH में जोड़ा जाएगा.

एब्सोल्यूट पाथ और / से शुरू होने वाले पाथ की अनुमति नहीं है. साथ ही, एक्ज़ीक्यूशन रूट के ऊपर किसी पाथ से जुड़े पाथ की वजह से गड़बड़ी हो सकती है.

legacy_create_init

Integer; optional; default is -1

अनजाने में, रन फ़ाइलें ट्री में खाली __init__.py फ़ाइल बनानी है या नहीं. इन्हें Python सोर्स कोड या शेयर की गई लाइब्रेरी वाली हर डायरेक्ट्री में बनाया जाता है. साथ ही, ये डायरेक्ट्री की हर पैरंट डायरेक्ट्री में बनाए जाते हैं. इसमें रेपो रूट डायरेक्ट्री शामिल नहीं होती. डिफ़ॉल्ट, अपने-आप का मतलब है कि जब तक --incompatible_default_to_explicit_init_py का इस्तेमाल नहीं किया जाता, तब तक यह सही है. अगर गलत हो, तो उपयोगकर्ता __init__.py वाली फ़ाइलें बनाने और उन्हें ज़रूरत के मुताबिक srcs के Python टारगेट में जोड़ने के लिए ज़िम्मेदार है.
main

Label; optional

उस सोर्स फ़ाइल का नाम जो ऐप्लिकेशन का मुख्य एंट्री पॉइंट है. यह फ़ाइल srcs में भी शामिल होनी चाहिए. अगर इसे तय नहीं किया गया है, तो इसके बजाय name का इस्तेमाल किया जाता है (ऊपर देखें). अगर name, srcs में मौजूद किसी भी फ़ाइल नाम से मेल नहीं खाता, तो main की जानकारी देना ज़रूरी है.
python_version

String; optional; nonconfigurable; default is "_INTERNAL_SENTINEL"

Python 2 या Python 3 के लिए, यह टारगेट (और इसके ट्रांज़िटिव deps) बनाना है या नहीं. मान्य वैल्यू "PY2" और "PY3" (डिफ़ॉल्ट) हैं.

Python वर्शन हमेशा रीसेट किया जाता है (डिफ़ॉल्ट रूप से) जो इस एट्रिब्यूट में बताए गए किसी भी वर्शन पर लागू होता है. कमांड लाइन पर दिए गए वर्शन या इस बात पर निर्भर अन्य टारगेट टारगेट वर्शन पर ध्यान दिए बिना.

अगर आपको मौजूदा Python वर्शन पर select() करना है, तो @rules_python//python:python_version की वैल्यू की जांच की जा सकती है. ज़्यादा जानकारी के लिए, यहां देखें.

गड़बड़ी की चेतावनी: यह एट्रिब्यूट वह वर्शन सेट करता है जिसके लिए बेज़ल आपका टारगेट बनाता है, लेकिन #4815 की वजह से, स्टब स्क्रिप्ट अब भी रनटाइम पर गलत अनुवादक वर्शन शुरू कर सकती है. यह तरीका देखें. इसमें py_runtime टारगेट के बारे में बताना शामिल है, जो ज़रूरत के हिसाब से Python वर्शन पर ले जाता है. साथ ही, --python_top को सेट करके, इस py_runtime को चालू करें.

srcs_version

String; optional; default is "PY2AND3"

यह एट्रिब्यूट बताता है कि टारगेट srcs का Python 2, Python 3 या दोनों के साथ काम करता है. असल में, Python रनटाइम वर्शन सेट करने के लिए, एक्ज़ीक्यूटेबल Python नियम (py_binary या py_test) का python_version एट्रिब्यूट इस्तेमाल करें.

इसका वैल्यू इस्तेमाल किया जा सकता है: "PY2AND3", "PY2", और "PY3". ऐतिहासिक वजहों से, "PY2ONLY" और "PY3ONLY" की वैल्यू भी दी जा सकती है. हालांकि, ये "PY2" और "PY3" जैसी ही होती हैं. इन्हें इस्तेमाल नहीं किया जाना चाहिए.

ध्यान दें कि सिर्फ़ एक्ज़ीक्यूटेबल नियमों (py_binary और py_library ) के लिए, Python के मौजूदा वर्शन की पुष्टि इस एट्रिब्यूट की वैल्यू से की जाती है. (यह एक सुविधा है; क्योंकि py_library, मौजूदा Python वर्शन में बदलाव नहीं करता है. अगर यह पुष्टि करता है, तो यह एक ही शुरू में PY2ONLY और PY3ONLY लाइब्रेरी, दोनों बनाना मुश्किल होगा.) इसके अलावा, अगर कोई वर्शन मेल नहीं खाता, तो गड़बड़ी को सिर्फ़ एक्ज़ीक्यूशन के दौरान रिपोर्ट किया जाता है. खास तौर पर, यह गड़बड़ी bazel build --nobuild शुरू करने पर नहीं दिखेगी.)

इस बात पर निर्भर करने के लिए कि किस डिपेंडेंसी से वर्शन से जुड़ी ज़रूरी शर्तें लागू होती हैं, अपने टारगेट पर find_requirements का इस्तेमाल किया जा सकता है:

          bazel build <your target> \
              --aspects=@rules_python//python:defs.bzl%find_requirements \
              --output_groups=pyversioninfo
          
इससे, -pyversioninfo.txt के साथ एक फ़ाइल बनेगी. इसमें आपको यह जानकारी दी जाएगी कि आपके टारगेट के लिए एक Python या किसी दूसरे वर्शन की ज़रूरत क्यों है. ध्यान दें कि यह नीति तब भी काम करती है, जब दिया गया वर्शन किसी वर्शन विवाद की वजह से न बना हो.

stamp

Integer; optional; default is 0

जांच के लिए, स्टैंप आर्ग्युमेंट को डिफ़ॉल्ट रूप से 0 पर सेट करने के अलावा, py_binary() आर्ग्युमेंट का सेक्शन देखें.

py_runtime

py_runtime(name, compatible_with, coverage_tool, deprecation, distribs, features, files, interpreter, interpreter_path, licenses, python_version, restricted_to, stub_shebang, tags, target_compatible_with, testonly, visibility)

यह Python कोड दिखाता है, जिसका इस्तेमाल Python कोड को चलाने के लिए किया जाता है.

py_runtime टारगेट, प्लैटफ़ॉर्म रनटाइम या इन-बिल्ट रनटाइम के बारे में बताता है. प्लैटफ़ॉर्म रनटाइम, किसी जाने-पहचाने पाथ पर सिस्टम से इंस्टॉल किए गए अनुवादक को ऐक्सेस करता है, जबकि इन-बिल्ड रनटाइम एक एक्ज़ीक्यूटेबल टारगेट पर ले जाता है, जो अनुवादक के तौर पर काम करता है. दोनों ही मामलों में, "interpreter" का मतलब है कि कोई भी एक्ज़ीक्यूटेबल बाइनरी या रैपर स्क्रिप्ट जो कमांड लाइन पर दी गई Python स्क्रिप्ट को चलाने में सक्षम है, जो मानक CPython अनुवादक के समान कन्वेंशन के मुताबिक होती है.

प्लैटफ़ॉर्म रनटाइम, अपने-आप में अलग है. यह टारगेट प्लैटफ़ॉर्म पर एक ज़रूरी शर्त लागू करता है कि एक अनुवादक किसी खास पाथ पर मौजूद है. इन-बिल्ड रनटाइम को किसी भी तरीके से इस्तेमाल किया जा सकता है या नहीं किया जा सकता. यह इस बात पर निर्भर करता है कि यह चेक-इन किए गए इंटरप्रटर पर ले जाता है या रैपर स्क्रिप्ट की ओर, जो सिस्टम अनुवादक की मदद लेता है.

उदाहरण:

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",
)

तर्क

विशेषताएं
name

Name; required

इस टारगेट के लिए कोई खास नाम.

coverage_tool

Label; optional

इस टारगेट के इस्तेमाल के लिए, py_binary और py_test टारगेट से कोड कवरेज की जानकारी इकट्ठा की जाती है.

सेट होने पर, टारगेट को एक ही फ़ाइल बनानी होगी या उसमें एक्ज़ीक्यूटेबल टारगेट होना चाहिए. किसी एक फ़ाइल का पाथ या टारगेट एक्ज़ीक्यूटेबल होने पर एक्ज़ीक्यूटेबल होता है, इससे Python की कवरेज टूल के लिए एंट्री पॉइंट तय होता है. टारगेट के साथ ही टारगेट की गई फ़ाइलें भी रन फ़ाइलें में जोड़ दी जाएंगी. ऐसा तब किया जाएगा, जब कवरेज चालू हो.

टूल के लिए एंट्री पॉइंट, Python में अनुवाद करने वाले टूल की मदद से लोड किया जाना चाहिए. उदाहरण के लिए, .py या .pyc फ़ाइल. इसे coverage.py के साथ कमांड लाइन आर्ग्युमेंट स्वीकार करने होंगे. इसके लिए, कम से कम run और lcov कमांड शामिल होने चाहिए.

files

List of labels; optional

इन-बिल्ड रनटाइम के लिए, यह फ़ाइलों का वह सेट होता है जिसमें यह रनटाइम होता है. इन फ़ाइलों को Python की बाइनरी की उन फ़ाइलों में जोड़ा जाएगा जो इस रनटाइम का इस्तेमाल करती हैं. प्लैटफ़ॉर्म रनटाइम के लिए, यह एट्रिब्यूट सेट नहीं किया जा सकता.
interpreter

Label; optional

इन-बिल्ड रनटाइम के लिए, यह टारगेट है कि अनुवादक के तौर पर शुरू होता है. प्लैटफ़ॉर्म रनटाइम के लिए, यह एट्रिब्यूट सेट नहीं किया जाना चाहिए.
interpreter_path

String; optional

प्लैटफ़ॉर्म रनटाइम के लिए, यह टारगेट प्लैटफ़ॉर्म पर Python अनुवादक का सटीक पाथ है. बिल्ड-इन रनटाइम के लिए, यह एट्रिब्यूट सेट नहीं किया जाना चाहिए.
python_version

String; optional; default is "_INTERNAL_SENTINEL"

यह रनटाइम, Python मेजर वर्शन 2 या 3 के लिए है. मान्य वैल्यू "PY2" और "PY3" हैं.

डिफ़ॉल्ट वैल्यू को --incompatible_py3_is_default फ़्लैग से कंट्रोल किया जाता है. हालांकि, आने वाले समय में यह एट्रिब्यूट ज़रूरी होगा और इसका कोई डिफ़ॉल्ट मान नहीं होगा.

stub_shebang

String; optional; default is "#!/usr/bin/env python3"

"Shebang" एक्सप्रेशन, py_binary टारगेट को लागू करते समय इस्तेमाल की जाने वाली बूटस्ट्रैपिंग Python स्टब स्क्रिप्ट से पहले जोड़ा गया.

ज़्यादा जानकारी के लिए, समस्या 8685 देखें.

Windows पर लागू नहीं होता है.