Python नियम

नियम

py_binary
py_library
py_test
py_runtime

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` में जोड़ी जाने वाली इंपोर्ट डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. ये इंपोर्ट इस नियम और इस पर निर्भर सभी नियमों के लिए डायरेक्ट्री जोड़ी जाएंगी (ध्यान दें: नहीं जिन नियमों पर यह नियम निर्भर करता है. हर डायरेक्ट्री को `PYTHONPATH` में इसके ज़रिए जोड़ दिया जाएगा `py_binary` नियम, जो इस नियम पर निर्भर हैं. ऐब्सलूट पाथ (`/` से शुरू होने वाले पाथ) और पाथ का रेफ़रंस देने वाले पाथ के बाद वाले उदाहरण को इस्तेमाल करने की अनुमति नहीं है और इससे गड़बड़ी हो सकती है.
`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"` Python 2 के लिए यह टारगेट (और इसके ट्रांज़िटिव `deps`) बनाना है या Python के लिए 3. मान्य वैल्यू, `"PY2"` और `"PY3"` (डिफ़ॉल्ट) हैं. Python वर्शन हमेशा किसी भी वर्शन पर रीसेट (डिफ़ॉल्ट रूप से) रहता है इस एट्रिब्यूट से तय किया जाता है. इससे कोई फ़र्क़ नहीं पड़ता कि कमांड लाइन पर या कमांड लाइन पर किस वर्शन ने जो इस पर निर्भर करते हैं. अगर आपको मौजूदा Python वर्शन पर `select()` करना है, तो मान `@rules_python//python:python_version` है. यहां जाएं: यहां हमारा वीडियो देखें. गड़बड़ी की चेतावनी: यह एट्रिब्यूट उस वर्शन को सेट करता है जिसके लिए Basel आपका टारगेट बनाता है, हालाँकि, #4815 की वजह से, नतीजे के तौर पर मिलने वाली स्टब स्क्रिप्ट, रनटाइम के दौरान अब भी अनुवादक के गलत वर्शन का इस्तेमाल कर सकती है. यहां जाएं: यह समाधान, जिसमें एक ऐसा `py_runtime` टारगेट तय करना शामिल है जो Python वर्शन में बदलाव कर सकता है और `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` में जोड़ी जाने वाली इंपोर्ट डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. ये इंपोर्ट इस नियम और इस पर निर्भर सभी नियमों के लिए डायरेक्ट्री जोड़ी जाएंगी (ध्यान दें: नहीं जिन नियमों पर यह नियम निर्भर करता है. हर डायरेक्ट्री को `PYTHONPATH` में इसके ज़रिए जोड़ दिया जाएगा `py_binary` नियम, जो इस नियम पर निर्भर हैं. ऐब्सलूट पाथ (`/` से शुरू होने वाले पाथ) और पाथ का रेफ़रंस देने वाले पाथ के बाद वाले उदाहरण को इस्तेमाल करने की अनुमति नहीं है और इससे गड़बड़ी हो सकती है.
`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` में जोड़ी जाने वाली इंपोर्ट डायरेक्ट्री की सूची. "वैरिएबल बनाएं" विकल्प पर निर्भर करता है. ये इंपोर्ट इस नियम और इस पर निर्भर सभी नियमों के लिए डायरेक्ट्री जोड़ी जाएंगी (ध्यान दें: नहीं जिन नियमों पर यह नियम निर्भर करता है. हर डायरेक्ट्री को `PYTHONPATH` में इसके ज़रिए जोड़ दिया जाएगा `py_binary` नियम, जो इस नियम पर निर्भर हैं. ऐब्सलूट पाथ (`/` से शुरू होने वाले पाथ) और पाथ का रेफ़रंस देने वाले पाथ के बाद वाले उदाहरण को इस्तेमाल करने की अनुमति नहीं है और इससे गड़बड़ी हो सकती है.
`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"` Python 2 के लिए यह टारगेट (और इसके ट्रांज़िटिव `deps`) बनाना है या Python के लिए 3. मान्य वैल्यू, `"PY2"` और `"PY3"` (डिफ़ॉल्ट) हैं. Python वर्शन हमेशा किसी भी वर्शन पर रीसेट (डिफ़ॉल्ट रूप से) रहता है इस एट्रिब्यूट से तय किया जाता है. इससे कोई फ़र्क़ नहीं पड़ता कि कमांड लाइन पर या कमांड लाइन पर किस वर्शन ने जो इस पर निर्भर करते हैं. अगर आपको मौजूदा Python वर्शन पर `select()` करना है, तो मान `@rules_python//python:python_version` है. यहां जाएं: यहां हमारा वीडियो देखें. गड़बड़ी की चेतावनी: यह एट्रिब्यूट उस वर्शन को सेट करता है जिसके लिए Basel आपका टारगेट बनाता है, हालाँकि, #4815 की वजह से, नतीजे के तौर पर मिलने वाली स्टब स्क्रिप्ट, रनटाइम के दौरान अब भी अनुवादक के गलत वर्शन का इस्तेमाल कर सकती है. यहां जाएं: यह समाधान, जिसमें एक ऐसा `py_runtime` टारगेट तय करना शामिल है जो Python वर्शन में बदलाव कर सकता है और `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() आर्ग्युमेंट का सेक्शन देखें कि स्टैम्प आर्ग्युमेंट, टेस्ट के लिए डिफ़ॉल्ट रूप से 0 पर सेट है.

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