BazelCon 2022, 16 नवंबर से 17 नवंबर तक न्यूयॉर्क में और ऑनलाइन उपलब्ध है.
आज ही रजिस्टर करें!

Python नियम

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

नियम

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 चलाना चाहते हैं (उदाहरण के लिए, किसी 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 फ़ाइलें बनाने और उन्हें ज़रूरत के मुताबिक Python के srcs टारगेट में जोड़ने की ज़िम्मेदारी लेता है.
main

Label; optional

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

String; optional; nonconfigurable; default is "_INTERNAL_SENTINEL"

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

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

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

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

srcs_version

String; optional; default is "PY2AND3"

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

ये मान इस्तेमाल किए जा सकते हैं: "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_version एट्रिब्यूट का इस्तेमाल करें, जो एक्ज़ीक्यूटेबल Python नियम (py_binary या py_test) का हो.

ये मान इस्तेमाल किए जा सकते हैं: "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 फ़ाइलें बनाने और उन्हें ज़रूरत के मुताबिक Python के srcs टारगेट में जोड़ने की ज़िम्मेदारी लेता है.
main

Label; optional

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

String; optional; nonconfigurable; default is "_INTERNAL_SENTINEL"

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

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

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

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

srcs_version

String; optional; default is "PY2AND3"

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

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

py_binary() तर्कों पर सेक्शन देखें, सिवाय इसके कि स्टैंप तर्क, टेस्ट के लिए डिफ़ॉल्ट रूप से शून्य पर सेट होता है.

py_रनटाइम

py_runtime(name, compatible_with, 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

Name; required

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

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" एक्सप्रेशन को पहले से चालू Python stub स्क्रिप्ट से पहले py_binary टारगेट लागू करते समय इस्तेमाल किया गया.

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

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