कॉन्टेंट की सूची
- पैकेज
- package_group (पैकेज_ग्रुप)
- exports_files
- ग्लोब
- चुनें
- सबपैकेज
पैकेज
package(default_deprecation, default_testonly, default_visibility, features)
यह फ़ंक्शन, मेटाडेटा में एलान करता है कि वह पैकेज के बाद के हर नियम पर लागू होता है. इसे पैकेज के अंदर ज़्यादा से ज़्यादा एक बार (BUILD फ़ाइल) इस्तेमाल किया जाता है.
पैकेज() फ़ंक्शन को किसी भी नियम से पहले, फ़ाइल के सबसे ऊपर सभी लोड() स्टेटमेंट के ठीक बाद कॉल किया जाना चाहिए.
तर्क
एट्रिब्यूट | ब्यौरा |
---|---|
default_visibility |
इस पैकेज में, नियमों के डिफ़ॉल्ट तौर पर दिखने का तरीका. इस पैकेज के हर नियम में, 'किसको दिखे' इस एट्रिब्यूट में दिखाया जाता है. ऐसा तब तक होता है, जब तक कि 'नियम' के |
default_deprecation |
इस पैकेज में, सभी नियमों के लिए डिफ़ॉल्ट
|
default_testonly |
इस पैकेज में, सभी नियमों के लिए डिफ़ॉल्ट
|
features |
इस BUILD फ़ाइल के सेमेंटिक को प्रभावित करने वाले विभिन्न फ़्लैग सेट करता है. इस सुविधा का इस्तेमाल मुख्य तौर पर, बिल्ड सिस्टम पर काम करने वाले लोग करते हैं. इससे वे पैकेज टैग करते हैं जिन्हें किसी खास तरह की हैंडलिंग की ज़रूरत होती है. इसका इस्तेमाल तब तक न करें, जब तक बिल्ड सिस्टम पर काम करने वाला कोई व्यक्ति इसे साफ़ तौर पर न कहे. |
उदाहरण
नीचे दी गई जानकारी में यह एलान किया गया है कि इस पैकेज में दिए गए नियम सिर्फ़ पैकेज ग्रुप//foo:target
के सदस्यों को दिखाई देते हैं. अगर किसी नियम के तहत 'किसको दिखाई दे' की जानकारी अलग से दी जाती है, तो इस खास जानकारी को बदल दें.
package(default_visibility = ["//foo:target"])
package_group (पैकेज_का_ग्रुप)
package_group(name, packages, includes)
यह फ़ंक्शन पैकेज के एक सेट के बारे में बताता है और ग्रुप को लेबल असाइन करता है. इस लेबल का संदर्भ visibility
विशेषताओं में दिया जा सकता है.
विज़िबिलिटी कंट्रोल के लिए, पैकेज ग्रुप का इस्तेमाल किया जाता है. आप एक या ज़्यादा पैकेज ग्रुप को किसी नियम का ऐक्सेस दे सकते हैं, पूरे सोर्स नियम के हर नियम को ऐक्सेस कर सकते हैं या सिर्फ़ उसी पैकेज में बताए गए नियमों को ऐक्सेस दे सकते हैं. विज़िबिलिटी सिस्टम की ज़्यादा जानकारी के लिए, किसको दिखाई दे एट्रिब्यूट देखें.
तर्क
एट्रिब्यूट | ब्यौरा |
---|---|
name |
इस टारगेट का एक यूनीक नाम. |
packages |
इस ग्रुप में पैकेज की पूरी जानकारी. पैकेज को डबल स्लैश से शुरू करते हुए, उनके पूरे नाम
का इस्तेमाल करने के बारे में बताया जाना चाहिए. उदाहरण के लिए, आप वाइल्डकार्ड भी तय कर सकते हैं: निर्देश
नेग को दिखाने के लिए पैकेज की खास बातों को अगर यह एट्रिब्यूट मौजूद नहीं है, तो पैकेज ग्रुप में कोई पैकेज शामिल नहीं होगा. हालांकि, इसमें अब भी दूसरे पैकेज ग्रुप शामिल हो सकते हैं. |
includes |
इस पैकेज में शामिल दूसरे पैकेज ग्रुप. इस एट्रिब्यूट में मौजूद लेबल, दूसरे पैकेज ग्रुप के हिसाब से होने चाहिए. बताए गए पैकेज ग्रुप के पैकेज, इस पैकेज ग्रुप का हिस्सा बन गए हैं. अगर यह पैकेज ग्रुप |
उदाहरण
package_group
के इस एलान में एक पैकेज ग्रुप बताया गया है, जिसे &ट्रॉट;ट्रॉपिकल&कोटेशन कहा जाता है; इसमें ट्रॉपिकल फल शामिल हैं.
package_group( name = "tropical", packages = [ "//fruits/mango", "//fruits/orange", "//fruits/papaya/...", ], )
नीचे दी गई जानकारी किसी काल्पनिक ऐप्लिकेशन के पैकेज समूह के बारे में बताती है:
package_group( name = "fooapp", includes = [ ":controller", ":model", ":view", ], ) package_group( name = "model", packages = ["//fooapp/database"], ) package_group( name = "view", packages = [ "//fooapp/swingui", "//fooapp/webui", ], ) package_group( name = "controller", packages = ["//fooapp/algorithm"], )
Exports_files
exports_files([label, ...], visibility, licenses)
exports_files()
इस पैकेज से जुड़ी फ़ाइलों की सूची देता है,
जिसे दूसरे पैकेज में एक्सपोर्ट किया जाता है.
किसी पैकेज की BUILD फ़ाइल सीधे तौर पर किसी दूसरे पैकेज की सोर्स फ़ाइलों से ही जुड़ी हो सकती है. इन फ़ाइलों को साफ़ तौर पर, exports_files()
स्टेटमेंट के साथ एक्सपोर्ट किया जाना चाहिए. फ़ाइलों की जानकारी के बारे में और पढ़ें.
पुराने तरीके के तौर पर, किसी नियम में इनपुट के तौर पर बताई गई फ़ाइलें भी डिफ़ॉल्ट तौर पर दिखती हैं. ऐसा तब तक होता है, जब तक कि फ़्लैग --incompatible_no_implicit_file_export
को फ़्लिप नहीं किया जाता. हालांकि, इस तरीके का इस्तेमाल नहीं करना चाहिए और न ही इसे छोड़कर जाने चाहिए.
तर्क
तर्क, मौजूदा पैकेज में फ़ाइलों के नामों की सूची होता है. यह
बताया जा सकता है कि दस्तावेज़ किसको दिखेगा.
इस मामले में, फ़ाइलें तय किए गए टारगेट को दिखेंगी. अगर कोई सेटिंग तय नहीं की गई है, तो फ़ाइलें हर पैकेज के लिए दिखेंगी. भले ही, पैकेज की डिफ़ाॅल्ट सुविधा के बारे में package
फ़ंक्शन में बताया गया हो. लाइसेंस
की जानकारी भी दी जा सकती है.
उदाहरण
नीचे दिए गए उदाहरण में golden.txt
को एक्सपोर्ट किया गया है. यह test_data
पैकेज की एक टेक्स्ट फ़ाइल होती है, ताकि दूसरे पैकेज इसका इस्तेमाल कर सकें. उदाहरण के लिए, जांच के data
एट्रिब्यूट में.
# from //test_data/BUILD exports_files(["golden.txt"])
ग्लोब
glob(include, exclude=[], exclude_directories=1, allow_empty=True)
Glob एक हेल्पर फ़ंक्शन है जो कुछ पाथ पैटर्न से मेल खाने वाली सभी फ़ाइलें ढूंढता है. साथ ही, उसके पाथ की एक नई और बदली गई सूची दिखाता है. Glob सिर्फ़ अपने पैकेज में फ़ाइलें खोजता है और सिर्फ़ स्रोत फ़ाइलों (न कि जनरेट की गई फ़ाइलों या दूसरे टारगेट) को खोजता है.
अगर फ़ाइल 's का पैकेज-रिलेटिव पाथ
किसी भी include
पैटर्न से मेल खाता है और कोई भी
exclude
पैटर्न नहीं है, तो नतीजे में स्रोत फ़ाइल का लेबल शामिल किया जाता है.
include
और exclude
सूचियों में पाथ पैटर्न शामिल हैं, जो मौजूदा पैकेज से मिलते-जुलते हैं. हर पैटर्न में एक या ज़्यादा पाथ सेगमेंट हो सकते हैं. हमेशा की तरह, यूनिक्स पाथ के साथ इन सेगमेंट को
/
से अलग किया जाता है. सेगमेंट में *
वाइल्डकार्ड हो सकता है: यह पाथ सेगमेंट में किसी भी सबस्ट्रिंग (भले ही खाली खाली स्ट्रिंग हो) से मेल खाता है. इसमें डायरेक्ट्री सेपरेटर /
शामिल नहीं है. इस वाइल्डकार्ड का इस्तेमाल एक पाथ सेगमेंट में
कई बार किया जा सकता है. इसके अलावा, **
वाइल्डकार्ड शून्य या ज़्यादा पूरे पाथ सेगमेंट से मेल खा सकता है. हालांकि, इसे अलग-अलग पाथ सेगमेंट के तौर पर बताया जाना चाहिए.
foo/bar.txt
, इस पैकेज में मौजूदfoo/bar.txt
फ़ाइल से पूरी तरह मेल खाता हैfoo/*.txt
,foo/
डायरेक्ट्री में मौजूद हर फ़ाइल से मेल खाता है. अगर फ़ाइल.txt
पर खत्म होती है, तोfoo/
सब-पैकेज नहीं हैfoo/a*.htm*
,foo/
डायरेक्ट्री में मौजूद हर उस फ़ाइल से मेल खाता है जोa
से शुरू होती है. इसके बाद, वह आर्बिट्ररी स्ट्रिंग हो सकती है (जो खाली हो सकती है). इसके बाद, वह.htm
होती है और किसी दूसरी आर्बिट्रेरी स्ट्रिंग से खत्म होती है; जैसे किfoo/axx.htm
औरfoo/a.html
याfoo/axxx.html
**/a.txt
, इस पैकेज की हर सबडायरेक्ट्री की हरa.txt
फ़ाइल से मेल खाता है**/bar/**/*.txt
, इस पैकेज की हर एक सबडायरेक्ट्री की हर.txt
फ़ाइल से मेल खाता है. ऐसा तब होता है, जब नतीजे वाले पाथ पर कम से कम एक डायरेक्ट्री,bar
कहा जाता है, जैसे किxxx/bar/yyy/zzz/a.txt
याbar/a.txt
(याद रखें कि**
भी शून्य सेगमेंट से मेल खाता है) याbar/zzz/a.txt
**
इस पैकेज की हर एक सबडायरेक्ट्री की हर फ़ाइल से मेल खाता हैfoo**/a.txt
एक अमान्य पैटर्न है, क्योंकि**
को सेगमेंट के तौर पर अपने-आप ही होना चाहिए
अगर exclude_directories
तर्क चालू होता है (1 पर सेट होता है), तो टाइप डायरेक्ट्री की फ़ाइलें, नतीजों से हटा दी जाएंगी (डिफ़ॉल्ट 1).
अगर allow_empty
आर्ग्युमेंट False
पर सेट है, तो नतीजा खाली होने पर glob
फ़ंक्शन गड़बड़ी दिखाएगा.
कई तरह की ज़रूरी सीमाएं और चेतावनियां हैं:
-
glob()
BUILD फ़ाइल इवैलुएशन के दौरान चलता है, इसलिएglob()
सिर्फ़ आपके सोर्स ट्री की फ़ाइलों से मेल खाता है. यह कभी भी जनरेट की गई फ़ाइलों से मेल नहीं खाता. अगर आप ऐसा टारगेट तैयार कर रहे हैं जिसके लिए सोर्स और जनरेट की गई, दोनों तरह की फ़ाइलों की ज़रूरत होती है, तो आपको ग्लोब में जनरेट की गई फ़ाइलों की सूची साफ़ तौर पर जोड़नी होगी. नीचे:mylib
और:gen_java_srcs
के साथ उदाहरण देखें. -
अगर किसी नियम का नाम, मेल खाने वाली स्रोत फ़ाइल के नाम जैसा है, तो नियम फ़ाइल को &शैडो और कोटेशन कर देगा.
इसे समझने के लिए, याद रखें कि
glob()
पाथ की सूची दिखाता है. इसलिए, दूसरे नियमों और #39; एट्रिब्यूट (जैसे,srcs = glob(["*.cc"])
) मेंglob()
का इस्तेमाल, मेल खाने वाले पाथ की सूची साफ़ तौर पर करने जैसा ही है. अगर उदाहरण के तौर पर,glob()
से["Foo.java", "bar/Baz.java"]
मिलता है, लेकिन यहां &&t3 ज़्यादा जानकारी के लिए, GitHub समस्या #10395 देखें. - ग्लोब, सबडायरेक्ट्री में मौजूद फ़ाइलों से मेल खा सकते हैं. साथ ही, सबडायरेक्ट्री के नामों को वाइल्डकार्ड किया जा सकता है. हालांकि...
-
लेबल के इस्तेमाल की अनुमति नहीं है.
उदाहरण के लिए, पैकेज
**/*.cc
केx
पैकेज में,x/y/z.cc
शामिल नहीं है, अगरx/y
पैकेज के तौर पर मौजूद है, तोx/y/BUILD
या पैकेज-पाथ पर कहीं और. इसका मतलब है कि ग्लोब एक्सप्रेशन का नतीजा असल में BUILD फ़ाइलों की मौजूदगी पर निर्भर करता है. इसका मतलब है कि अगरx/y
पैकेज नहीं होता, तो ग्लोब एक्सप्रेशन मेंx/y/z.cc
शामिल हो जाता है या --delete_packages फ़्लैग का इस्तेमाल करके इसे मिटाया गया माना जाता है. - ऊपर दिया गया प्रतिबंध सभी ग्लोब एक्सप्रेशन पर लागू होता है, चाहे वे किसी भी वाइल्डकार्ड का इस्तेमाल करते हों.
-
.
के नाम से छिपी हुई फ़ाइल के नाम की शुरुआत**
से और*
वाइल्डकार्ड, दोनों से पूरी तरह होती है. अगर आप किसी छिपी हुई फ़ाइल को किसी कंपाउंड पैटर्न से मिलाना चाहते हैं, तो पैटर्न.
से शुरू होना चाहिए. उदाहरण के लिए,*
और.*.txt
,.foo.txt
से मेल खाएंगे. हालांकि,*.txt
इस्तेमाल नहीं करेंगे. छिपे हुए डायरेक्ट्री भी उसी तरह मेल खाते हैं. छिपी हुई डायरेक्ट्री में ऐसी फ़ाइलें शामिल हो सकती हैं जो इनपुट के तौर पर ज़रूरी नहीं हैं. साथ ही, ये ग़ैर-ज़रूरी फ़ाइलों और मेमोरी की ज़रूरत को बढ़ा सकती हैं. छिपी हुई डायरेक्ट्री हटाने के लिए, उन्हें &quat;excluded&कोटेशन; सूची के आर्ग्युमेंट में जोड़ें. -
&quat;**&कोटेशन; वाइल्डकार्ड का एक कोने वाला केस है: पैटर्न
"**"
पैकेज/#39;पैकेज के डायरेक्ट्री पाथ से मेल नहीं खाता है. इसका मतलब यह है किglob(["**"], exclude_directories = 0)
, सभी पैकेज और डायरेक्ट्री को मौजूदा पैकेज और उसकी डायरेक्ट्री के तहत ट्रांज़िट समय में पूरी तरह मेल खाता है. हालांकि, इसमें सबपैकेज की डायरेक्ट्री का इस्तेमाल नहीं किया जा सकता. इसके बारे में पिछला नोट देखें.
आम तौर पर, ग्लोब पैटर्न के लिए सिर्फ़ '*' का इस्तेमाल करने के बजाय, सही एक्सटेंशन देने की कोशिश करें. ज़्यादा साफ़ नाम अपने-आप दस्तावेज़ बनाना और यह पक्का करता है कि आप बैक अप फ़ाइलों या emacs/vi/... की फ़ाइलों को अपने-आप सेव न करें.
बिल्ड के नियम लिखते समय, ग्लोब के एलिमेंट का ब्यौरा दिया जा सकता है. इससे हर इनपुट के लिए अलग-अलग नियम जनरेट होते हैं. नीचे दिया गया बड़ा ग्लोब उदाहरण सेक्शन देखें.
ग्लोब के उदाहरण
इस डायरेक्ट्री की सभी Java फ़ाइलों और :gen_java_srcs
नियम से जनरेट की गई सभी फ़ाइलों की मदद से एक Java लाइब्रेरी बनाएं.
java_library( name = "mylib", srcs = glob(["*.java"]) + [":gen_java_srcs"], deps = "...", ) genrule( name = "gen_java_srcs", outs = [ "Foo.java", "Bar.java", ], ... )
प्रयोग के तौर पर शुरू की गई.txt फ़ाइल को छोड़कर, डायरेक्ट्री टेस्टडेटा में सभी txt फ़ाइलों को शामिल करें. ध्यान रखें कि टेस्ट डेटा की सबडायरेक्ट्री की फ़ाइलें शामिल नहीं की जाएंगी. अगर आप उन फ़ाइलों को शामिल करना चाहते हैं, तो बार-बार होने वाले ग्लोब (**) का इस्तेमाल करें.
sh_test( name = "mytest", srcs = ["mytest.sh"], data = glob( ["testdata/*.txt"], exclude = ["testdata/experimental.txt"], ), )
बार-बार होने वाले ग्लोब के उदाहरण
टेस्ट को टेस्ट डेटा डायरेक्ट्री और उसकी सभी सबडायरेक्ट्री (और उनकी सबडायरेक्ट्री वगैरह) की सभी टेक्स्ट फ़ाइलों पर निर्भर करता है. BUILD फ़ाइल वाली सबडायरेक्ट्री को अनदेखा कर दिया जाता है. (ऊपर दी गई सीमाएं और चेतावनियां देखें.)
sh_test( name = "mytest", srcs = ["mytest.sh"], data = glob(["testdata/**/*.txt"]), )
इस डायरेक्ट्री में सभी Java फ़ाइलों और सभी सबडायरेक्ट्री से बनाई गई लाइब्रेरी बनाएं. इनमें वे डायरेक्ट्री शामिल नहीं हैं जिनके पाथ में, डायरेक्ट्री नाम की डायरेक्ट्री शामिल है. अगर संभव हो, तो इस पैटर्न से बचना चाहिए, क्योंकि इससे बिल्ड की बढ़ोतरी कम हो सकती है और इसलिए बिल्ड का समय बढ़ सकता है.
java_library( name = "mylib", srcs = glob( ["**/*.java"], exclude = ["**/testing/**"], ), )
बड़े ग्लोब के उदाहरण
मौजूदा डायरेक्ट्री में *_test.cc के लिए अलग-अलग नियम बनाएं, जो फ़ाइल में लाइनों की संख्या की गिनती करता है.
# Conveniently, the build language supports list comprehensions. [genrule( name = "count_lines_" + f[:-3], # strip ".cc" srcs = [f], outs = ["%s-linecount.txt" % f[:-3]], cmd = "wc -l $< >$@", ) for f in glob(["*_test.cc"])]
अगर ऊपर दी गई BUILD फ़ाइल पैकेज //foo में है और पैकेज में तीन मैचिंग फ़ाइलें हैं, a_test.cc, b_test.cc और c_test.cc फिर, जो चल रहा है
bazel query '//foo:all'
जनरेट किए गए सभी नियमों की सूची बनाएगा:
$ bazel query '//foo:all' | sort //foo:count_lines_a_test //foo:count_lines_b_test //foo:count_lines_c_test
चुनें
select( {conditionA: valuesA, conditionB: valuesB, ...}, no_match_error = "custom message" )
select()
, हेल्पर फ़ंक्शन है. यह नियम के एट्रिब्यूट को कॉन्फ़िगर किया जा सकता है.
यह
करीब-करीब किसी भी एट्रिब्यूट असाइनमेंट के दाईं ओर बदल सकता है. इसलिए, इसका मान कमांड-लाइन बेज़ल के फ़्लैग पर निर्भर करता है.
उदाहरण के लिए, आप इसका इस्तेमाल, प्लैटफ़ॉर्म के हिसाब से डिपेंडेंसी तय करने या अलग-अलग रिसॉर्स को एम्बेड करने के लिए कर सकते हैं. यह इस बात पर निर्भर करता है कि नियम हमेशा "developer"
बनाम &kot;release&quat; मोड में बनाया गया है या नहीं.
बुनियादी इस्तेमाल नीचे दिया गया है:
sh_binary( name = "mytarget", srcs = select({ ":conditionA": ["mytarget_a.sh"], ":conditionB": ["mytarget_b.sh"], "//conditions:default": ["mytarget_default.sh"] }) )
इससे, sh_binary
के srcs
एट्रिब्यूट को कॉन्फ़िगर किया जा सकता है. इसके लिए, लेबल सेट करने की सामान्य प्रक्रिया को select
कॉल से बदला जाता है. यह कॉल, कॉन्फ़िगरेशन की शर्तों को मैप करने वाली वैल्यू से मैप करता है. हर शर्त, config_setting
या constraint_value
की जानकारी देने वाला लेबल है, जो टारगेट और #39; का कॉन्फ़िगरेशन वैल्यू के अनुमानित सेट से मेल खाता है. इसके बाद, mytarget#srcs
की वैल्यू मौजूदा
लेबल से मेल खाने वाली लेबल सूची बन जाती है.
ध्यान दें:
- शुरू करने पर, सिर्फ़ एक शर्त चुनी जाती है.
- अगर एक से ज़्यादा शर्तें मेल खाती हैं और एक शर्त दूसरों की विशेषज्ञता है, तो विशेषज्ञता को प्राथमिकता दी जाती है. शर्त B को स्थिति A की विशेषता माना जाता है. इसका मतलब यह भी है कि विशेषज्ञता रिज़ॉल्यूशन को ऑर्डर करने के लिए डिज़ाइन नहीं किया गया है, जैसा कि नीचे उदाहरण 2 में दिखाया गया है.
- अगर एक से ज़्यादा शर्तें मेल खाती हैं और एक शर्त पूरी नहीं होती है, तो गड़बड़ी की वजह से बज़ेल किसी गड़बड़ी की वजह से काम नहीं कर पाता.
- अगर कोई दूसरी शर्त मेल नहीं खाती है, तो स्यूडो-लेबल
//conditions:default
का खास मिलान किया जाता है. अगर यह स्थिति खत्म हो जाती है, तो कोई दूसरा नियम किसी गड़बड़ी से बचने के लिए मेल खाना चाहिए. select
को एक बड़े एट्रिब्यूट असाइनमेंट के अंदर एम्बेड किया जा सकता है. इसलिए,srcs = ["common.sh"] + select({ ":conditionA": ["myrule_a.sh"], ...})
औरsrcs = select({ ":conditionA": ["a.sh"]}) + select({ ":conditionB": ["b.sh"]})
मान्य एक्सप्रेशन हैं.select
, ज़्यादातर एट्रिब्यूट के साथ काम करता है, लेकिन सभी एट्रिब्यूट के साथ नहीं. काम न करने वाले एट्रिब्यूट को उनके दस्तावेज़ मेंnonconfigurable
के तौर पर मार्क किया गया है.सब-पैकेज
subpackages(include, exclude=[], allow_empty=True)
subpackages()
एक हेल्पर फ़ंक्शन है, जोglob()
की तरह है. इसमें फ़ाइलों और डायरेक्ट्री के बजाय सबपैकेज शामिल होते हैं. यहglob()
के पाथ पाथ पैटर्न का इस्तेमाल करता है. साथ ही, यह ऐसे किसी भी सबपैकेज का मिलान कर सकता है जो फ़िलहाल, BUILD की फ़ाइल लोड हो रहा है. शामिल करने और निकालने के पैटर्न की ज़्यादा जानकारी और उदाहरणों के लिए, ग्लोब देखें.दिखाए गए सबपैकेज की सूची, क्रम में लगाई गई है. इसमें, लोड होने वाले मौजूदा पैकेज के हिसाब से पाथ शामिल हैं. ये पाथ,
include
में दिए गए पैटर्न से मेल खाते हैं, न किexclude
के पैटर्न से.उदाहरण
नीचे दिए गए उदाहरण में, पैकेज के लिए सभी डायरेक्ट सबपैकेज दिए गए हैं
foo/BUILD
# The following BUILD files exist: # foo/BUILD # foo/bar/baz/BUILD # foo/sub/BUILD # foo/sub/deeper/BUILD # # In foo/BUILD a call to subs = subpackages(include = ["**"]) # results in subs == ["sub", "bar/baz"] # # 'sub/deeper' is not included because it is a subpackage of 'foo/sub' not of # 'foo'
आम तौर पर, यह प्राथमिकता दी जाती है कि इस फ़ंक्शन को सीधे कॉल करने के बजाय, उपयोगकर्ता #sky9 के मॉड्यूल का इस्तेमाल करते हैं.