Python नियम

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

नियम

py_binary

नियम का सोर्स देखें 
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 चलाना है, तो सही तरीका यह है कि आप दूसरी बाइनरी या टेस्ट को अपने डेटा सेक्शन में py_binary पर निर्भर करें. उदाहरण के लिए, किसी java_test में कुछ मॉक रिसॉर्स सेट अप करने के लिए, python बाइनरी चलाना. इसके बाद, दूसरा बिनेरी, सोर्स डायरेक्ट्री के हिसाब से py_binary को ढूंढ सकता है. 

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

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

तर्क

विशेषताएं
name

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.


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

लेबल की सूची; डिफ़ॉल्ट [] है

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

लेबल की सूची; ज़रूरी है

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

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

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

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

legacy_create_init

पूर्णांक; डिफ़ॉल्ट वैल्यू -1 है

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

लेबल; डिफ़ॉल्ट None है

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

स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट "_INTERNAL_SENTINEL" है

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

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

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

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

srcs_version

स्ट्रिंग; डिफ़ॉल्ट रूप से "PY2AND3"

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

इन वैल्यू का इस्तेमाल किया जा सकता है: "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

पूर्णांक; डिफ़ॉल्ट वैल्यू -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

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
deps

लेबल की सूची; डिफ़ॉल्ट [] है

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

लेबल की सूची; डिफ़ॉल्ट [] है

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

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

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

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

srcs_version

स्ट्रिंग; डिफ़ॉल्ट रूप से "PY2AND3"

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

इन वैल्यू का इस्तेमाल किया जा सकता है: "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

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
deps

लेबल की सूची; डिफ़ॉल्ट [] है

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

लेबल की सूची; ज़रूरी है

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

स्ट्रिंग की सूची; डिफ़ॉल्ट रूप से []

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

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

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

legacy_create_init

पूर्णांक; डिफ़ॉल्ट वैल्यू -1 है

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

लेबल; डिफ़ॉल्ट None है

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

स्ट्रिंग; कॉन्फ़िगर नहीं की जा सकती; डिफ़ॉल्ट "_INTERNAL_SENTINEL" है

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

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

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

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

srcs_version

स्ट्रिंग; डिफ़ॉल्ट रूप से "PY2AND3"

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

इन वैल्यू का इस्तेमाल किया जा सकता है: "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

पूर्णांक; डिफ़ॉल्ट वैल्यू 0 है

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

py_runtime

नियम का सोर्स देखें 
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)

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

py_runtime टारगेट, प्लैटफ़ॉर्म रनटाइम या इन-बिल्ड रनटाइम में से किसी एक को दिखा सकता है. प्लैटफ़ॉर्म रनटाइम, सिस्टम में पहले से इंस्टॉल किए गए इंटरप्रेटर को किसी जाने-पहचाने पाथ पर ऐक्सेस करता है. वहीं, इन-बिल्ड रनटाइम, एक्ज़ीक्यूटेबल टारगेट पर ले जाता है, जो इंटरप्रेटर के तौर पर काम करता है. दोनों मामलों में, "इंटरप्रेटर" का मतलब किसी भी ऐसी एक्सीक्यूटेबल बाइनरी या रैपर स्क्रिप्ट से है जो कमांड लाइन पर भेजी गई 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

नाम; यह ज़रूरी है

इस टारगेट के लिए यूनीक नाम.
bootstrap_template

लेबल; डिफ़ॉल्ट "@bazel_tools//tools/python:python_bootstrap_template.txt" है

इसे पहले "Python स्टब स्क्रिप्ट" कहा जाता था. यह हर Python executable टारगेट का एंट्री पॉइंट है.
coverage_tool

लेबल; डिफ़ॉल्ट None है

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

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

टूल के एंट्री पॉइंट को Python इंटरप्रेटर (जैसे, .py या .pyc फ़ाइल) से लोड किया जा सकता हो. यह coverage.py की कमांड लाइन आर्ग्युमेंट को स्वीकार करना चाहिए. इसमें कम से कम run और lcov सब-कमांड शामिल होने चाहिए.

files

लेबल की सूची; डिफ़ॉल्ट [] है

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

लेबल; डिफ़ॉल्ट None है

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

स्ट्रिंग; डिफ़ॉल्ट रूप से ""

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

स्ट्रिंग; डिफ़ॉल्ट रूप से "_INTERNAL_SENTINEL"

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

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

stub_shebang

स्ट्रिंग; डिफ़ॉल्ट रूप से "#!/usr/bin/env python3"

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

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

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