इसे एक ही चरण के रूप में करने का कोई तरीका नहीं है, लेकिन दो चरणों की प्रक्रिया के रूप में करना आसान है।
उपयोग:
python bootstrap.py
./bin/buildout install cython
./bin/cpy bootstrap.py
./bin/cpy ./bin/buildout
buildout इस तरह एक अस्पष्ट विकल्प जो कोई भी कभी भी के बारे में बातचीत इंस्टॉल का समर्थन करता है, लेकिन आप उपयोग कर सकते हैं क्योंकि, कारण यह संभव है:
[buildout]
parts = deps py # <---- Notice we don't depend on cython here
eggs =
whatever
kdist
nark
kivy # <--- But we do have a module that requires cython to build
develop =
.
lib/nark
lib/kivy-dist
[cython] # <---- By calling ./bin/buildout install cython we trigger this
recipe = zc.recipe.egg:script
parts = cython-py
interpreter = cpy # <--- Which makes our dummy ./bin/cpy
eggs =
cython
pyinstaller
[deps]
recipe = zc.recipe.egg:eggs
eggs = ${buildout:eggs}
[py]
recipe = zc.recipe.egg:script
interpreter = py
eggs = ${buildout:eggs}
इस दृष्टिकोण के बारे में प्यारी बात यह है कि बिल्डिंग बिल्डआउट दूसरी बार दिन के अंत में बिन निर्देशिका साफ़ करता है, तो आपको एक बिन निर्देशिका के साथ छोड़ दिया जाता है इस तरह उक्स:
$ ls bin/
buildout garden py
नहीं बचे हुए संकुल कि या अपने virtualenv में चारों ओर लटका नहीं हो सकता है और ऊपर पेंच बातें बाद में। यही कारण है कि हम पहले स्थान पर बिल्डआउट का उपयोग क्यों कर रहे हैं?
... जाहिर है, अगर आप cython चारों ओर मस्ती करना चाहते हैं, यह शीर्ष पर निर्भरता में छड़ी के साथ-साथ juts।
क्या आप वाकई Cython ठीक से स्थापित है और आप 'PYTHONPATH' वातावरण चर निर्धारित किया है dir जहां Cython मॉड्यूल रहते हैं शामिल करने के लिए कर रहे हैं? –
क्या आपका सिस्टम स्तर पर मतलब था? इससे सिथन के बिना सिस्टम पर इस बिल्डआउट को तैनात नहीं किया जा सकता है ...? –
"सिस्टम स्तर" से आपका क्या मतलब है? –