سؤال

يتم تثبيت Python في دليل محلي.

تبدو شجرة الدليل الخاصة بي مثل هذا:

(local directory)/site-packages/toolkit/interface.py

الكود الخاص بي هنا:

(local directory)/site-packages/toolkit/examples/mountain.py

لتشغيل المثال ، أكتب python mountain.py, وفي الكود لدي:

from toolkit.interface import interface

وأحصل على الخطأ:

Traceback (most recent call last):
  File "mountain.py", line 28, in ?
    from toolkit.interface import interface
ImportError: No module named toolkit.interface

لقد راجعت بالفعل sys.path وهناك لدي الدليل /site-packages. أيضا ، لدي الملف __init__.py.bin في مجلد مجموعة الأدوات للإشارة إلى Python أن هذه حزمة. لدي أيضا ملف __init__.py.bin في دليل الأمثلة.

لا أعرف لماذا لا يمكن لـ Python العثور على الملف عندما يكون في sys.path. أيه أفكار؟ هل يمكن أن تكون مشكلة أذونات؟ هل أحتاج إلى بعض إذن التنفيذ؟

هل كانت مفيدة؟

المحلول

بناءً على تعليقاتك على منشور Orip ، أعتقد أن هذا ما حدث:

  1. قمت بتحرير __init__.py على Windows.
  2. أضاف محرر Windows شيئًا غير طباعة ، وربما عائد النقل (نهاية الخط في Windows هو CR/LF ؛ في Unix هو LF فقط) ، أو ربما CTRL-Z (Windows End-Of Lefle).
  3. لقد استخدمت WINSCP لنسخ الملف إلى مربع UNIX الخاص بك.
  4. فكر WINSCP: "هذا يحتوي على نص ليس أساسيًا ؛ سأضع امتدادًا .bin للإشارة إلى البيانات الثنائية."
  5. المفقودين __init__.py (ينادى الآن __init__.py.bin) يعني أن Python لا يفهم مجموعة الأدوات كحزمة.
  6. انت صنعت __init__.py في الدليل المناسب وكل شيء يعمل ...؟

نصائح أخرى

يفعل

(local directory)/site-packages/toolkit

عند __init__.py?

لجعل الاستيراد مشي من خلال دلائلك ، يجب أن يكون لكل دليل __init__.py ملف.

على *nix ، تأكد أيضًا من تكوين Pythonpath بشكل صحيح ، خاصة أنه يحتوي على هذا التنسيق:

 .:/usr/local/lib/python

(مانع .: في البداية ، بحيث يمكنه البحث على الدليل الحالي أيضًا.)

قد يكون أيضًا في مواقع أخرى ، اعتمادًا على الإصدار:

 .:/usr/lib/python
 .:/usr/lib/python2.6
 .:/usr/lib/python2.7 and etc.

واجهت شيئًا مشابهًا جدًا عندما فعلت هذا التمرين في LPTHW ؛ لم أتمكن من الحصول على Python على إدراك أن لدي ملفات في الدليل الذي كنت أتصل منه. لكنني تمكنت من العمل في النهاية. ما فعلته ، وما أوصي به ، هو تجربة هذا:

(ملاحظة: من مشاركتك الأولية ، أفترض أنك تستخدم جهازًا قائمًا على *NIX وتشغيل الأشياء من سطر الأوامر ، لذلك تم تصميم هذه النصيحة لذلك. بما أنني أدير Ubuntu ، هذا ما فعلته)

1) تغيير الدليل (CD) إلى الدليل في الاعلى الدليل حيث ملفاتك. في هذه الحالة ، تحاول تشغيل mountain.py الملف ، ومحاولة الاتصال toolkit.interface.py الوحدة النمطية ، التي هي في أدلة منفصلة. في هذه الحالة ، ستذهب إلى الدليل الذي يحتوي على مسارات لكل من الملفات (أو بعبارة أخرى ، أقرب دليل يشاركه مسارات كلا الملفتين). التي في هذه الحالة هي toolkit الدليل.

2) عندما تكون في tookit الدليل ، أدخل هذا السطر من الكود في سطر الأوامر الخاص بك:

export PYTHONPATH=.

هذا يحدد pythonpath الخاص بك إلى "." ، مما يعني في الأساس أن pythonpath سوف يبحث الآن عن أي ملفات تسمى داخل الدليل الذي تكون فيه حاليًا ، (وأكثر من ذلك إلى حد ، في فروع الدليل الفرعي من الدليل الذي أنت فيه. لذلك لا ينظر فقط في دليلك الحالي ، ولكن في جميع الدلائل الموجودة في دليلك الحالي).

3) بعد تعيين Pythonpath الخاص بك في الخطوة أعلاه ، قم بتشغيل الوحدة النمطية الخاصة بك من الدليل الحالي ( toolkit الدليل). يجب أن يجد Python الآن وحملا الوحدات النمطية التي حددتها.

أتمنى أن يساعدك هذا. شعرت بالإحباط الشديد من هذا بنفسي.

لقد حلت مشكلتي الخاصة ، وسأكتب ملخصًا للأشياء التي كانت خاطئة والحل:

يجب استدعاء الملف بالضبط __init__.py. إذا كان التمديد مختلفًا كما في حالتي .py.bin ثم لا يمكن لـ Python التحرك عبر الدلائل ومن ثم لا يمكن العثور على الوحدات النمطية. لتحرير الملفات التي تحتاجها لاستخدام محرر Linux ، مثل السادس أو نانو. إذا كنت تستخدم محرر Windows ، فسوف يكتب هذا بعض الأحرف المخفية.

هناك مشكلة أخرى كانت تؤثر على ذلك وهي أن لدي نسخة أخرى من Python مثبتة بواسطة الجذر ، لذلك إذا كان شخص ما يعمل مع تثبيت محلي لـ Python ، فتأكد من أن تثبيت Python الذي يدير البرامج هو Python المحلي. للتحقق من هذا ، فقط افعل which python, ، ومعرفة ما إذا كان القابل للتنفيذ هو الشخص الموجود في الدليل المحلي الخاص بك. إذا لم يكن الأمر كذلك ، فقم بتغيير المسار ، ولكن تأكد من أن دليل Python المحلي موجود من قبل Python الآخر.

لوضع علامة على دليل كحزمة تحتاج إلى ملف مسمى __init__.py, هل هذا يساعد؟

الحل السهل هو تثبيت الوحدة باستخدام python -m pip install <library-name> بدلاً من pip install <library-name>يمكنك استخدام sudo في حالة قيود المسؤول

استخدام PyCharm (جزء من جناح Jetbrains) تحتاج إلى تحديد دليل البرنامج النصي الخاص بك كمصدر:
Right Click > Mark Directory as > Sources Root

نعم. تحتاج إلى الدليل لاحتواء __init__.py الملف ، وهو الملف الذي يهيئة الحزمة. هنا ، ألق نظرة على هذه.

ملفات __init__.py مطلوبة لجعل Python تعامل الدلائل على أنها تحتوي على حزم ؛ يتم ذلك لمنع الدلائل ذات الاسم المشترك ، مثل String ، من إخفاء وحدات صالحة عن غير قصد تحدث لاحقًا على مسار البحث عن الوحدة النمطية. في أبسط حالة ، يمكن أن يكون __init__.py مجرد ملف فارغ ، ولكن يمكنه أيضًا تنفيذ رمز التهيئة للحزمة أو تعيين متغير __All__ ، الموضح لاحقًا.

  1. يجب أن يكون لديك الملف __ init__.py في نفس الدليل حيث يكون الملف الذي تستورده.
  2. لا يمكنك محاولة استيراد ملف له نفس الاسم وأن يكون ملفًا من مجلدين تم تكوينه على Pythonpath.

على سبيل المثال: /إلخ /البيئة

pythonpath = $ pythonpath:/opt/folder1:/opt/folder2

/OPT/FOLDER1/FOO

/OPT/FOLDER2/FOO

وإذا كنت تحاول استيراد ملف FOO ، فلن يعرف Python أي شخص تريده.

من Foo Import ... >>> المستورد: لا توجد وحدة تدعى Foo

My two cents:

enter image description here

Spit:

Traceback (most recent call last):
      File "bash\bash.py", line 454, in main
        import bosh
      File "Wrye Bash Launcher.pyw", line 63, in load_module
        mod = imp.load_source(fullname,filename+ext,fp)
      File "bash\bosh.py", line 69, in <module>
        from game.oblivion.RecordGroups import MobWorlds, MobDials, MobICells, \
    ImportError: No module named RecordGroups

This confused the hell out of me - went through posts and posts suggesting ugly syspath hacks (as you see my __init__.py were all there). Well turns out that game/oblivion.py and game/oblivion was confusing python which spit out the rather unhelpful "No module named RecordGroups". I'd be interested in a workaround and/or links documenting this (same name) behavior -> EDIT (2017.01.24) - have a look at What If I Have a Module and a Package With The Same Name? Interestingly normally packages take precedence but apparently our launcher violates this.

EDIT (2015.01.17): I did not mention we use a custom launcher dissected here.

Linux: Imported modules are located in /usr/local/lib/python2.7/dist-packages

If you're using a module compiled in C, don't forget to chmod the .so file after sudo setup.py install.

sudo chmod 755 /usr/local/lib/python2.7/dist-packages/*.so

You are reading this answer says that your __init__.py is in the right place, you have installed all the dependencies and you are still getting the ImportError.

I was facing a similar issue except that my program would run fine when ran using PyCharm but the above error when I would run it from the terminal. After digging further, I found out that PYTHONPATH didn't have the entry for the project directory. So, I set PYTHONPATH per Import statement works on PyCharm but not from terminal:

export PYTHONPATH=$PYTHONPATH:`pwd`  (OR your project root directory)

There's another way to do this using sys.path as:

import sys
sys.path.insert(0,'<project directory>') OR
sys.path.append('<project directory>')

You can use insert/append based on the order in which you want your project to be searched.

In my case, the problem was I was linking to debug python & boost::Python, which requires that the extension be FooLib_d.pyd, not just FooLib.pyd; renaming the file or updating CMakeLists.txt properties fixed the error.

My problem was that I added the directory with the __init__.py file to PYTHONPATH, when actually I needed to add its parent directory.

If you have tried all methods provided above but failed, maybe your module has the same name as a built-in module. Or, a module with the same name existing in a folder that has a high priority in sys.path than your module's.

To debug, say your from foo.bar import baz complaints ImportError: No module named bar. Changing to import foo; print foo, which will show the path of foo. Is it what you expect?

If not, Either rename foo or use absolute imports.

In my case, because I'm using PyCharm and PyCharm create a 'venv' for every project in project folder, but it is only a mini env of python. Although you have installed the libraries you need in Python, but in your custom project 'venv', it is not available. This is the real reason of 'ImportError: No module named xxxxxx' occurred in PyCharm. To resolve this issue, you must add libraries to your project custom env by these steps:

  • In PyCharm, from menu 'File'->Settings
  • In Settings dialog, Project: XXXProject->Project Interpreter
  • Click "Add" button, it will show you 'Available Packages' dialog
  • Search your library, click 'Install Package'
  • Then, all you needed package will be installed in you project custom 'venv' folder.

Settings dialog

Enjoy.

Fixed my issue by writing print (sys.path) and found out that python was using out of date packages despite a clean install. Deleting these made python automatically use the correct packages.

To all those who still have this issue. I believe Pycharm gets confused with imports. For me, when i write 'from namespace import something', the previous line gets underlined in red, signaling that there is an error, but works. However ''from .namespace import something' doesn't get underlined, but also doesn't work.

Try

try:
    from namespace import something 
except NameError:
    from .namespace import something

After just suffering the same issue I found my resolution was to delete all pyc files from my project, it seems like these cached files were somehow causing this error.

Easiest way I found to do this was to navigate to my project folder in Windows explorer and searching for *.pyc, then selecting all (Ctrl+A) and deleting them (Ctrl+X).

Its possible I could have resolved my issues by just deleting the specific pyc file but I never tried this

I faced the same problem: Import error. In addition the library've been installed 100% correctly. The source of the problem was that on my PC 3 version of python (anaconda packet) have been installed). This is why the library was installed no to the right place. After that I just changed to the proper version of python in the my IDE PyCharm.

I had the same error. It was caused by somebody creating a folder in the same folder as my script, the name of which conflicted with a module I was importing from elsewhere. Instead of importing the external module, it looked inside this folder which obviously didn't contain the expected modules.

I had the same problem (Python 2.7 Linux), I have found the solution and i would like to share it. In my case i had the structure below:

Booklet
-> __init__.py
-> Booklet.py
-> Question.py
default
-> __init_.py
-> main.py

In 'main.py' I had tried unsuccessfully all the combinations bellow:

from Booklet import Question
from Question import Question
from Booklet.Question import Question
from Booklet.Question import *
import Booklet.Question
# and many othet various combinations ...

The solution was much more simple than I thought. I renamed the folder "Booklet" into "booklet" and that's it. Now Python can import the class Question normally by using in 'main.py' the code:

from booklet.Booklet import Booklet
from booklet.Question import Question
from booklet.Question import AnotherClass

From this I can conclude that Package-Names (folders) like 'booklet' must start from lower-case, else Python confuses it with Class names and Filenames.

Apparently, this was not your problem, but John Fouhy's answer is very good and this thread has almost anything that can cause this issue. So, this is one more thing and I hope that maybe this could help others.

In my case I was including the path to package.egg folder rather than the actual package underneath. I copied the package to top level and it worked.

This worked for me: Created __init__.py file inside parent folder (in your case, inside site-packages folder). And imported like this:

from site-packages.toolkit.interface import interface

Hope it will be useful for you as well !

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top