इन फ़ंक्शन को @bazel_tools//tools/build_defs/repo:local.bzl से लोड किया जा सकता है.
लोकल फ़ाइल सिस्टम में मौजूद डायरेक्ट्री को रेपो के तौर पर उपलब्ध कराने के नियम.
सेटअप
मॉड्यूल एक्सटेंशन में इन नियमों का इस्तेमाल करने के लिए, उन्हें अपनी .bzl फ़ाइल में लोड करें. इसके बाद, उन्हें अपने एक्सटेंशन के लागू करने वाले फ़ंक्शन से कॉल करें. उदाहरण के लिए, local_repository का इस्तेमाल करने के लिए:
load("@bazel_tools//tools/build_defs/repo:local.bzl", "local_repository")
def _my_extension_impl(mctx):
  local_repository(name = "foo", path = "foo")
my_extension = module_extension(implementation = _my_extension_impl)
इसके अलावा, use_repo_rule की मदद से, MODULE.bazel फ़ाइल में इन repo नियमों को सीधे तौर पर कॉल किया जा सकता है:
local_repository = use_repo_rule("@bazel_tools//tools/build_defs/repo:local.bzl", "local_repository")
local_repository(name = "foo", path = "foo")
local_repository
load("@bazel//tools/build_defs/repo:local.bzl", "local_repository")
local_repository(name, path, repo_mapping)
यह ऐसी लोकल डायरेक्ट्री को रेपो के तौर पर उपलब्ध कराता है जिसमें पहले से ही Bazel फ़ाइलें मौजूद हैं. इस डायरेक्ट्री में, Bazel BUILD फ़ाइलें और repo boundary फ़ाइल पहले से मौजूद होनी चाहिए. अगर इसमें ये फ़ाइलें नहीं हैं, तो new_local_repository का इस्तेमाल करें.
ATTRIBUTES
| name | नाम; ज़रूरी है इस रिपॉज़िटरी के लिए यूनीक नाम. | 
| path | स्ट्रिंग; ज़रूरी है उस डायरेक्ट्री का पाथ जिसे रेपो के तौर पर उपलब्ध कराना है. पाथ, वर्कस्पेस के रूट के हिसाब से पूरा या उससे मिलता-जुलता हो सकता है. | 
| repo_mapping | Dictionary: String -> String; optional सिर्फ़ `WORKSPACE` कॉन्टेक्स्ट में: लोकल रिपॉज़िटरी के नाम से लेकर ग्लोबल रिपॉज़िटरी के नाम तक का डिक्शनरी. इससे इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, `"@foo": "@bar"` एंट्री से यह पता चलता है कि जब भी यह रिपॉज़िटरी `@foo` पर निर्भर करती है (जैसे कि `@foo//some:target` पर निर्भरता), तो इसे असल में, वैश्विक तौर पर एलान किए गए `@bar` (`@bar//some:target`) के अंदर उस निर्भरता को हल करना चाहिए. यह एट्रिब्यूट, `MODULE.bazel` कॉन्टेक्स्ट में काम _नहीं_ करता. ऐसा तब होता है, जब मॉड्यूल एक्सटेंशन के लागू करने वाले फ़ंक्शन के अंदर रिपॉज़िटरी के नियम को लागू किया जाता है. | 
new_local_repository
load("@bazel//tools/build_defs/repo:local.bzl", "new_local_repository")
new_local_repository(name, build_file, build_file_content, path, repo_mapping)
यह ऐसी लोकल डायरेक्ट्री को रेपो के तौर पर उपलब्ध कराता है जिसमें Bazel फ़ाइलें शामिल नहीं होती हैं. इस डायरेक्ट्री में Bazel BUILD फ़ाइलें या repo boundary फ़ाइल शामिल करने की ज़रूरत नहीं है. इन्हें यह repo rule बनाएगा. अगर डायरेक्ट्री में पहले से ही Bazel फ़ाइलें मौजूद हैं, तो local_repository का इस्तेमाल करें.
ATTRIBUTES
| name | नाम; ज़रूरी है इस रिपॉज़िटरी के लिए यूनीक नाम. | 
| build_file | लेबल; ज़रूरी नहीं है इस रेपो के लिए, BUILD फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. 
 इस लेबल से जुड़ी फ़ाइल का नाम BUILD होना ज़रूरी नहीं है. हालांकि, ऐसा किया जा सकता है. असली BUILD फ़ाइलों से इसे अलग दिखाने के लिए,  | 
| build_file_content | स्ट्रिंग; ज़रूरी नहीं इस रेपो के लिए बनाई जाने वाली BUILD फ़ाइल का कॉन्टेंट. 
 | 
| path | स्ट्रिंग; ज़रूरी है उस डायरेक्ट्री का पाथ जिसे रेपो के तौर पर उपलब्ध कराना है. पाथ, वर्कस्पेस के रूट के हिसाब से पूरा या उससे मिलता-जुलता हो सकता है. | 
| repo_mapping | Dictionary: String -> String; optional सिर्फ़ `WORKSPACE` कॉन्टेक्स्ट में: लोकल रिपॉज़िटरी के नाम से लेकर ग्लोबल रिपॉज़िटरी के नाम तक का डिक्शनरी. इससे इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, `"@foo": "@bar"` एंट्री से यह पता चलता है कि जब भी यह रिपॉज़िटरी `@foo` पर निर्भर करती है (जैसे कि `@foo//some:target` पर निर्भरता), तो इसे असल में, वैश्विक तौर पर एलान किए गए `@bar` (`@bar//some:target`) के अंदर उस निर्भरता को हल करना चाहिए. यह एट्रिब्यूट, `MODULE.bazel` कॉन्टेक्स्ट में काम _नहीं_ करता. ऐसा तब होता है, जब मॉड्यूल एक्सटेंशन के लागू करने वाले फ़ंक्शन के अंदर रिपॉज़िटरी के नियम को लागू किया जाता है. |