प्लगइन केस स्टडी: प्लगी – एली बेंडरस्कीची वेबसाइट

प्लगइन केस स्टडी: प्लगी – एली बेंडरस्कीची वेबसाइट


अलीकडेच मी Pluggy वर आलो, प्लगइन सिस्टम विकसित करण्यासाठी Python लायब्ररी. हे मूलतः भाग म्हणून विकसित केले गेले pytest प्रकल्प – त्याच्या समृद्ध प्लगइन इकोसिस्टमसाठी ओळखला जातो – आणि नंतर स्टँडअलोन लायब्ररीमध्ये काढला. तुम्हाला तुमच्या टूल किंवा लायब्ररीमध्ये प्लगइन सिस्टम जोडायची असल्यास आणि तुमच्या स्वत:चा रोल करण्याऐवजी सिद्ध केलेले काहीतरी वापरायचे असल्यास तुम्हाला प्लग्गीशी संपर्क साधावा लागेल.

या पोस्टमध्ये मी प्लगी कसे कार्य करते यावर काही टिपा सामायिक करेन आणि नंतर ते प्लगइन इन्फ्रास्ट्रक्चरच्या मूलभूत संकल्पनांशी कसे संरेखित होते याचे पुनरावलोकन करेन.

प्लगइन केस स्टडी: प्लगी – एली बेंडरस्कीची वेबसाइट

प्लगी वापरणे

च्या संकल्पनेभोवती प्लगी बांधले आहे हुक: फंक्शन्स जे होस्ट ऍप्लिकेशन्स किंवा टूल्स (येथून, फक्त “होस्ट”) एक्सपोज करतात आणि प्लगइन्स अंमलात आणतात. यजमान परत आलेल्या डेकोरेटरचा वापर करून हुक उघड करतो pluggy.HookspecMarker आणि एक प्लगइन या हुकमधून परत आलेल्या डेकोरेटरचा वापर करते pluggy.HookimplMarker.

प्लगीचे दस्तऐवजीकरण हे बऱ्यापैकी स्पष्ट करते; या पोस्टमध्ये, मी कसे अंमलात आणायचे ते दर्शवू htmlize माझ्या प्लगइन मालिकेतील मूळ लेखात सादर केलेले काही प्लगइन असलेले साधन.

आठवण म्हणून, htmlize हे एक टॉय टूल आहे जे restructuredText प्रमाणेच मार्कअप नोटेशन घेते आणि ते HTML मध्ये रूपांतरित करते. हे सानुकूल “भूमिका” हाताळण्यासाठी प्लगइनना समर्थन देते जसे:

some text :role:`customized text` and more text

तसेच प्लगइन जे संपूर्ण मजकूरावर अनियंत्रित प्रक्रिया करतात.

हुक परिभाषित करणे

आउट होस्ट दोन हुक परिभाषित करतो:

import pluggy

hookspec = pluggy.HookspecMarker("htmlize")

@hookspec(firstresult=True)
def htmlize_role_handler(role_name):
    """Return a function accepting role contents.

    The function will be called with a single argument - the role contents, and
    should return what the role gets replaced with.
    """
    pass

@hookspec
def htmlize_contents(post, db):
    """Return a function accepting full document contents.

    The function will be called with a single argument - the document contents
    (after paragraph splitting and role processing), and should return the
    transformed contents.
    """
    pass

कॉल करून एक हुक तयार केला जातो हुकस्पेक मार्कर प्रकल्पाच्या नावासह. या प्रकल्पाचे नाव होस्ट आणि त्याचे प्लगइन यांच्यात जुळले पाहिजे. हुक पॅरामीटर्स म्हणून काय स्वीकारतात आणि ते काय परत करतात याबद्दल प्लगी परवानगी आहे; जास्तीत जास्त लवचिकतेसाठी आणि मूळवर खरे राहण्यासाठी htmlize उदाहरणार्थ, आमचे हुक रिटर्न फंक्शन्स.

या सोबत हुकस्पेक मार्करहोस्ट देखील परिभाषित करतो a हुकिम्पलमार्कर त्याच नावाने:

hookimpl = pluggy.HookimplMarker("htmlize")

हे प्लगइन लोड झाल्यावर हुक जोडण्यासाठी वापरले जाते.

होस्टमध्ये प्लगइन लोड करत आहे

होस्टचे मुख्य फंक्शन स्टार्टअपवर खालीलप्रमाणे प्लगइन लोड करते:

pm = pluggy.PluginManager("htmlize")
pm.add_hookspecs(hookspecs)
pm.load_setuptools_entrypoints("htmlize")

हुकस्पेक्स आमचे पायथन मॉड्यूल आहे ज्यामध्ये वर दर्शविलेले हुक आहेत.
load_setuptools_entrypoints प्लगइन लोड करण्यासाठी प्लगीचा मदतनीस आहे pip-समान वातावरणात स्थापित आणि सेटअप टूल्स एंट्री पॉइंट म्हणून नोंदणीकृत. हे सिग्नल करण्याचा एक मार्ग आहे – एखाद्याच्या मध्ये setup.py किंवा pyproject.toml फाइल – काही मेटाडेटा ज्याचे प्रोजेक्ट रनटाइममध्ये पुनरावलोकन करू शकतात. आमच्या प्रकल्पात, प्लगइन या विभागात स्वतःची नोंदणी करतात pyproject.toml फाइल:

(project.entry-points.htmlize)
tt = "tt"

हे म्हणतात “प्रवेश बिंदूसाठी htmlizeनावाची नवीन नोंद परिभाषित करा tt“. प्लगीज load_setuptools_entrypoints नंतर ही माहिती ऍक्सेस करण्यासाठी importlib.metadata वापरते.

लक्षात ठेवा की प्लगीला ही यंत्रणा वापरण्याची आवश्यकता नाही. यजमान त्यांना हवी असलेली कोणतीही प्लगइन शोध पद्धत लागू करू शकतात आणि त्यांच्यामध्ये थेट प्लगइन जोडू शकतात
प्लगइन मॅनेजर सह नोंदणी करा पद्धत पण यासाठी वापरली जाणारी यंत्रणा आहे pytest आणि इतर अनेक प्रकल्प; हे स्थापित केलेले प्लगइन स्वयंचलितपणे शोधणे आणि नोंदणी करणे खूप सोपे करते pip आणि समतुल्य साधने.

प्लगइन्सची विनंती करत आहे

एकदा प्लगइन मॅनेजर प्लगइन लोड करते, त्यांना आवाहन करणे सोपे आहे; कसे ते येथे आहे htmlize सामग्री हुक आमंत्रित करते:

# Build full contents back again, and ask plugins to act on
# contents.
contents = ''.join(parts)
for handler in plugin_manager.hook.htmlize_contents(post=post, db=db):
    contents = handler(contents)
return contents

साधारणपणे, हुक इनव्होकेशन रिटर्न a यादी वेगवेगळ्या प्लगइन्सद्वारे जोडलेल्या सर्व हुकपैकी (एकाच होस्ट ऍप्लिकेशनमध्ये एकाधिक प्लगइन स्थापित केले जाऊ शकतात आणि त्याच हुकला जोडले जाऊ शकतात). जेव्हा होस्ट वर दर्शविल्याप्रमाणे हुक लावतो तेव्हा डीफॉल्ट ऑर्डर LIFO असते, परंतु प्लगइन हुक पर्यायांसह प्रभावित करू शकतात. प्रथम प्रयत्न करा आणि ट्रायलास्ट.

प्लगइनमध्ये हुक लागू करणे

येथे आमचे संपूर्ण आहे narcissist सामग्री हुकशी संलग्न असलेले प्लगइन:

import htmlize

@htmlize.hookimpl
def htmlize_contents(post, db):
    repl = f'I ({post.author})'

    def hook(contents):
        return re.sub(r'\bI\b', repl, contents)

    return hook

काही टिपा:

  • अपेक्षा करतो htmlize स्थापित करणे; आधी चर्चा केल्याप्रमाणे, आम्ही Pluggy च्या डीफॉल्ट इंस्टॉल-आधारित पध्दतीवर अवलंबून आहोत जेथे होस्ट आणि प्लगइन दोन्ही एकाच Python वातावरणात स्थापित केले जातात आणि अशा प्रकारे एकमेकांना शोधू शकतात. तथापि, प्लगी कोणत्याही सानुकूल शोध पद्धतीचे समर्थन करते.
  • ते वापरते हुकिमप्ल पूर्वी दर्शविलेले निर्यात मूल्य.
  • हे एक फंक्शन देते जे सामग्रीवर कार्य करते; हे आहे htmlize-विशिष्ट करार (एबीआय, जर तुम्ही कराल) आम्ही आधी चर्चा केली आहे.

या केस स्टडीमधील मूलभूत प्लगइन संकल्पना

Pluggy चा हा केस स्टडी या ब्लॉगवर अनेक वेळा कव्हर केलेल्या मूलभूत प्लगइन संकल्पनांवर कसा उपाय करतो ते पाहू या.

हे लक्षात ठेवणे महत्त्वाचे आहे की प्लगी हा बेस्पोक प्लगइन प्रणालीसह विशिष्ट होस्ट अनुप्रयोग नाही; त्याऐवजी, अशा प्लगइन सिस्टम तयार करण्यासाठी ही एक पुन्हा वापरता येण्याजोगी लायब्ररी आहे. म्हणून, हे अधिक आहे मेटा केस स्टडी.

शोध

साधारणपणे, प्लगी शोध तर्कशास्त्र वापरकर्त्याच्या विवेकबुद्धीनुसार सोडते. त्याची
प्लगइन मॅनेजर आहे नोंदणी करा प्लगइन जोडण्याची पद्धत, आणि हे अनुप्रयोग निवडलेल्या कोणत्याही मार्गाने शोधले जाऊ शकते.

असे म्हटले आहे की, Pluggy वर दर्शविल्याप्रमाणे, Python पॅकेजिंगच्या एंट्री पॉइंट प्रक्रियेद्वारे – एक शोध यंत्रणा अंगभूत आहे. मोठ्या संख्येने ऍप्लिकेशन्ससाठी हे अत्यंत सोयीचे आहे, जोपर्यंत ऍप्लिकेशन आणि त्याचे प्लगइन दोन्ही मानक पायथन पॅकेजिंग टूल्सद्वारे स्थापित केले जातात (जे पायथन इकोसिस्टममध्ये एक अतिशय वाजवी गृहीतक आहे).

नोंदणी

एंट्री पॉइंट प्रक्रियेत, प्लगइन्स a जोडून स्वतःची नोंदणी करतात
(project.entry-points.) त्यांच्या मध्ये विभाग pyproject.toml
फाइल

अन्यथा – मागील विभागाप्रमाणे – वापरकर्ते त्यांच्या स्वतःच्या नोंदणी योजना तयार करण्यास मोकळे आहेत.

हुक

हे एक सोपे आहे, कारण ते म्हणतात हुक प्लगी भाषेतही! प्लगइन्स सेट करण्यासाठी प्लगइन्ससाठी फंक्शन डेकोरेटर्ससह, हुकची अंमलबजावणी खूपच सुंदर आहे. याचे उदाहरण आपण वर पाहिले आहे
@htmlize.hookimpl सजावट htmlize_contents.

प्लगइनवर अनुप्रयोग API उघड करणे

Pluggy हे Python होस्ट आणि Python प्लगइनसाठी डिझाइन केलेले असल्याने, हे अगदी सरळ आहे. प्लगइन्स सहसा असे गृहीत धरतात की होस्ट प्रोजेक्ट आधीपासूनच पायथन वातावरणात स्थापित केलेला आहे आणि त्याचे मॉड्यूल आयात केले जाऊ शकतात.

आमच्या उदाहरणात, हुकिमप्ल पासून आयात केले जाते htmlize हे पूर्ण करण्यासाठी प्लगइनद्वारे. हे प्लगइनवर होस्ट डेटा कसा पास केला जातो हे देखील दर्शविते – द
पोस्ट आणि db पॅरामीटर्स हे प्लगइन्सच्या वापरासाठी होस्टद्वारे उघड केलेले API आहेत.

निष्कर्ष – प्लगी हे योग्य आहे का?

प्लगइन इन्फ्रास्ट्रक्चर पोस्टच्या माझ्या मूळ मूलभूत संकल्पनांच्या तळटीप 2 मध्ये, मी लिहिले:

त्यामुळेच कदाचित फार कमी सु-स्थापित प्लगइन फ्रेमवर्क अस्तित्वात आहेत (अगदी C किंवा C++ सारख्या निम्न-स्तरीय भाषांमध्येही). आपले स्वतःचे रोल करणे खूप सोपे (आणि मोहक) आहे.

मला अजूनही विश्वास आहे की माझे विधान सत्य आहे – प्लगइन फ्रेमवर्क तयार करणे खूप सोपे आहे आणि ते प्रदान केलेली कार्यक्षमता त्यांच्या मोठ्या पृष्ठभागाच्या तुलनेत तुलनेने लहान आहे. दुसऱ्या शब्दांत, हे ए उथळ API.

ते म्हणाले, प्लगइनच्या अधिक प्रगत वापरांसाठी प्लगी काही छान कार्यक्षमता प्रदान करते:

  • स्वयंचलित एंट्री पॉइंट नोंदणी यंत्रणा – जर तुम्हाला त्याची गरज असेल
  • स्वाक्षरी प्रमाणीकरण
  • एकाच प्लगइनमधील एकाधिक हुक संलग्नकांवर आणि अनेक प्लगइनवर सातत्यपूर्ण प्लगइन परिणाम संग्रह
  • सह ऑर्डरिंग प्लगइन पहिला परिणाम, प्रथम प्रयत्न करा, ट्रायलास्टइ.
  • काही विशेष वापराच्या प्रकरणांसाठी हुक “रॅपर्स”.

तुमच्या प्रकल्पासाठी हे फायदेशीर आहेत का? हे खरोखर प्रकल्पावर अवलंबून असते, आणि अवलंबित्व आणि प्रकल्प प्रयत्न यांच्यातील ट्रेडऑफ लक्षात ठेवणे नेहमीच फायदेशीर असते.



Source link

Postagens Similares

  • Expérimenter le parrainage pour mon blog et ma newsletter

    19 février 2026 J’ai longtemps résisté à l’idée d’accepter un parrainage pour mon blog. J’apprécie ma crédibilité en tant que voix indépendante et je ne veux pas risquer de compromettre cette réputation. Ensuite, j’ai découvert l’approche de Troy Hunt en matière de parrainage, dont il a parlé pour la première fois en 2016. Troy fonctionne…

  • بن کا استعمال کرتے ہوئے خود ساختہ ٹائپ اسکرپٹ پروگرام

    بون خود بخود انحصار انسٹال کرنا اگر آپ مجھ سے اتنا ہی نفرت کرتے ہیں تو شاید انحصار کی وجہ سے۔ وقت کا تقریبا 23 23-319 ٪ ، جب میں ایک ازگر ایپ چلاتا ہوں تو ، یہ انحصار کی وجہ سے کام نہیں کرتا ہے ، اور میں یہ جاننے کی کوشش کرتا ہوں…

  • Следуя алгоритму | Дэниел Мисслер

    У меня только что было странное предчувствие, что в 2026 году мы получим результаты, подобные ASI, от ИИ, но не от новой модели. Это будет из петель. И, возможно, в частности, один цикл, который я иногда называю Последним алгоритмом или Основополагающим алгоритмом. Что-то крутое. Алгоритм заслуживает крутого слова. Мне кажется, что если мы столкнемся с…

  • Steve Yegge の予測記録

    私は予測を避けるようにしています。これは勝ちのない命題です。もしあなたが正しければ、後知恵バイアスにより、あなたが明白なことを指摘しているように見えてしまいます。そして、ほとんどの予測は外れます。時々、誰かが専門家の予測をレビューするとき、それらはほとんどの場合、少なくともランダムな偶然から予想される以上に間違っており、その後、後知恵バイアスにより、それぞれの予測が滑稽なほど悪いものに見えます。 しかし、時折、かなり確実で自明ではない予測をする人に遭遇することがあります。 Steve Yegge の古い作品を再読していたのですが、彼もそのような人物の 1 人であることがわかりました。 彼の最も有名な予測はおそらく JavaScript の台頭でしょう。これは後から考えると信じられないほど明白であるため、Gary Bernhardt の『JavaScript の誕生と死』で描かれている未来は少なくとも少しはもっともらしく思えます。しかし、スティーブのブログのコメントと、HN、reddit、その他のいつもの容疑者からのコメントの両方を読めば、当時のスティーブの予測がいかに自明ではなかったのかがわかります。 スティーブはまた、2004 年に未来について 10 件の予測を投稿するほど非常に勇敢でした。彼は「それらのほとんどはおそらく間違っています。演習のポイントは演習そのものであり、どのような結果が得られるかではありません。」と述べていますが、その予測は実際にはかなり合理的です。 予測 #1: 2011 年までに XML データベースの人気がリレーショナル データベースを超えるだろう 2011 年は少し早すぎたかもしれませんし、JSON は正確には XML ではありませんが、NoSQL データベースは、「O/R マッピングを好んで行う人はいません。誰もがソリューションを求めているだけです。」という予測に示されたほぼ理由により、非常にうまくいっていました。確かに、Mongo ではデータが失われる可能性がありますが、セットアップと使用は簡単です。 予測 #2: 誰かがオープンソース Web アプリケーションをホスティングして大金を稼ぐだろう これは「たくさん」が何を意味するかによって異なりますが、これは基本的に正しいようです。 私たちはホスト型 Web サービスの時代に急速に突入しており、大企業はスケーラブルなインフラストラクチャを活用して、専門知識を持たない企業のためにデータとコンピューティングをホストしています。 振り返ってみると不可解に思える理由ですが、Amazon は主要な競合他社よりもずっと前からこのことを理解しており、他の競合他社に大きく先んじてスタートを切ることができました。 Azure が開始されたのは 2009 年であり、Google がパブリック クラウド ホスティングに本格的に取り組んだのはさらに後になってからでした。 Steve が 2004 年に予測したことを誰もが理解した今、どの企業もパブリック クラウド製品を立ち上げようとしているように見えますが、市場の競争は非常に激しく、雇用は非常に困難になっています。アリババは、市場価格の整数倍を上回る多数のオファーを出してきたにもかかわらず、依然として競争力のあるパブリッククラウドを組み立てることができるチームをまとめることができておらず、アリババほど多くの現金を費やさずに今このゲームに参入しようとしている企業は、さらに困難な状況に直面している。…

  • تنفيذ أجهزة الحالة في PostgreSQL · Felix Geisendörfer

    تم النشر: 27 يوليو 2017 تعد آلة الحالة المحدودة (FSM) نموذجًا رائعًا للحساب وله العديد من التطبيقات العملية. أحد الأشياء المفضلة لدي هو تحويل منطق الأعمال إلى ولايات ميكرونيزيا الموحدة البسيطة. على سبيل المثال، ضع في اعتبارك المتطلبات التالية لنظام إدارة الطلبات: يجب ألا يتم شحن الطلبات قبل أن يتم دفعها. يمكن إلغاء الطلبات، ولكن…

  • میری ٹوڈو لسٹ میں سب سے اوپر

    اپریل 2012 برونی ویئر نامی ایک فالج کی دیکھ بھال کرنے والی نرس نے مرنے والوں کے سب سے بڑے پچھتاوے کی فہرست بنائی۔ اس کی فہرست قابل فہم معلوم ہوتی ہے۔ میں خود کو دیکھ سکتا تھا – کر سکتے ہیں خود کو دیکھیں — ان 5 میں سے کم از کم 4 غلطیاں…

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *