Ipython: تم تثبيت IPython داخل Virtualenv. تحذير "الرجاء تثبيت IPython داخل Virtualtenv"

حاول طباعة هذه من داخل IPython:

import os, sys, IPython
print os.environ['VIRTUAL_ENV']
print sys.executable
print IPython.__file__
print sys.path

شكرا مينرك. فيما يلي النواتج:

قبل أن أتصل بـ IPython من سطر الأوامر ، يظهر موجهتي بشكل صحيح على النحو التالي:
([name of virtual env]) [my regular prompt]

ثم ، بمجرد وصولي إلى IPython:

print os.environ['VIRTUAL_ENV']
# correctly prints the path to the environment 

print sys.executable
# Prints the external path to Python (?)

print IPython.__file__
# Prints the external path to the ipython installation's __init__.pyc (?)

print sys.path
# Prints the path to the site-packages folder from the virtualenv at the top.
# Then the bin path of the Python's external installation (?)
# Then some paths to individual packages from the external installation (?)
# Then the paths to individual packages from the virtualenv (and it misses the virtualenv's installation of IPython, ?)
# Then a few more paths to individual packages of the external installation (?)
# Finally the IPython from the external installation (?)

إذا خرجت من جلسة IPython الخاصة بي ، فستظهر موجهاتي بشكل صحيح على النحو التالي:
([name of virtual env]) [my regular prompt]

للتوضيح ، عندما أقول تثبيتًا خارجيًا _ ، أعني تثبيتًا _not * داخل virtualenv ، وليس جزءًا من تثبيت نظام أيضًا ، ولكن التثبيت الذي قمت بتضمينه أعلى $PATH و $LD_LIBRARY_PATH وأنا أعلم أنه يعمل بشكل صحيح.

ربما يكون هناك متغير بيئة مفقود وهذا يربك IPython للاعتقاد بأنني أستخدم تثبيت النظام وليس التثبيت الخارجي الذي أريد استخدامه مع Virtualenv الخاص بي والذي أقوم بتضمينه في بداية PATH و LD_LIBRARY_PATH ؟

ماذا تحصل بـ head $(which ipython) ؟

واحد آخر: sys.argv

إذا كان sys.executable خاطئًا ، فحينئذٍ ساءت الأمور قبل تحميل أي حزم من حزم Python. هذا هو بالضبط ما سيحدث إذا كان النظام ipython بدلاً من نظام مثبت في البيئة (على سبيل المثال ، إذا قمت بعمل /usr/bin/ipython مع env نشط ، والذي يجب أن نتوقع جميعًا أن يكون تصرفًا سيئًا).

من الممكن أن يكون الإصلاح بسيطًا مثل hash -r ، هل يمكنك تجربة ذلك؟

شكرا مينرك. إرجاع head $(which ipython) :

#!/path_to_my_virtual_env/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'ipython==0.13.1','console_scripts','ipython'
__requires__ = 'ipython==0.13.1'
import sys
from pkg_resources import load_entry_point

sys.exit(
   load_entry_point('ipython==0.13.1', 'console_scripts', 'ipython')()
)

ويعيد print sys.argv المسار إلى تثبيت Python الخارجي.

يبدو أن تشغيل hash -r من المحطة قد نجح!

أنا الآن أتلقى تحذيرًا مختلفًا على الرغم من ذلك
WARNING: IPython History requires SQLite, your history will not be saved

وهو أمر مثير للاهتمام ، لأنني لا أحصل على هذه الرسالة إذا قمت بإلغاء تنشيط virtualenv الخاصة بي وتشغيل ipython من التثبيت الخارجي.

أفترض أن هذا ما فعلته:

1. قمت بتشغيل ipython ورأيت هذا التحذير
2. قمت بتثبيت ipython في البيئة المحيطة
3. في نفس جلسة shell ، حاولت تشغيل ipython مرة أخرى

إليك المعلومات ذات الصلة ، ولماذا تم إصلاحها بواسطة hash -r :

• يتم تخزين مسار الأوامر مؤقتًا بعد استدعائها ، لذلك لا يبحث في الواقع عن PATH عن أمر معين أكثر من مرة في جلسة shell.
• لا يعرف which ذاكرة التخزين المؤقت هذه ، لذا لا يشير which ipython بالضرورة إلى ipython الذي سيتم استدعاؤه إذا تم استدعاؤه من قبل في جلسة shell.
• يعيد hash -r ببساطة تعيين ذاكرة التخزين المؤقت هذه ، بحيث يصبح which دقيقًا مرة أخرى.

بالنسبة إلى sqlite ، ما لغة Python التي استخدمتها في Virtualenv؟

minrk نعم ، هذا صحيح! شكرا. أنا أستخدم Python 2.7 x64

هل قمت ببناء بايثون بنفسك؟ إذا كان الأمر كذلك ، فأنت بحاجة إلى التأكد من وجود libsqlite ومتاح عند تجميع Python.

شكرا مينرك. يبدو أن libsqlite متاحًا لـ IPython الخارجي ، أي الذي أقوم بتشغيله عندما لا أقوم بتنشيط البيئة الافتراضية (على الرغم من أن هذه ليست البيئة من تثبيت النظام ، حيث قمت بتعديل PATH و LD_LIBRARY_PATH لتضمين تثبيت خارجي في الأعلى). ومع ذلك ، أعتقد أنه من المحتمل أن IPython الخارجي يستخدم libsqlite من تثبيت النظام (ربما من مسارات أخرى في LD_LIBRARY_PATH ). هل إصلاح الأجهزة التجارية؟

في كلتا الحالتين ، شكرا مرة أخرى على كل ما تبذلونه من المساعدة. تم حل المشكلة الأصلية التي أبلغت عنها ، حتى نتمكن من إغلاق التذكرة بأمان.

إنها مشكلة وقت تجميع بشكل عام - أعتقد أنك بحاجة إلى الرؤوس ، وما إلى ذلك (لا يمكنك إصلاحها دون إعادة تجميع Python)

لقد قمت بتعيين البرنامج التنفيذي لملف تعريف .py على Notebook ، لذلك لم يتم تشغيله مطلقًا!
ثم أجدها！
شكرا لك!