глобальный/приложение Lib папки импорта в Django

У меня есть структура Django, как это (только с указанием ЛИЭС):глобальный/приложение Lib папки импорта в Django

project/lib/ # Global libraries that will be used cross apps 
project/lib/global_stuff.py 
project/apps/app1/lib/special_for_app1.py 
project/apps/app2/lib/special_for_app2.py

Некоторые приложения не имеют Lib папки.

from apps.app1.lib import special_for_app1 работает нормально. Но как я могу импортировать из глобальной папки lib, когда я внутри папки, уже содержащей локальную папку lib?

Изнутри приложений views.py файл на одном из приложений:

from lib import global_stuff

дает мне ImportError: cannot import name global_stuff

из .lib импорта global_stuff

дает мне ImportError: cannot import name global_stuff

from ..lib import global_stuff

дает мне ImportError: No module named lib

from ...lib import global_stuff

дает мне ValueError: Attempted relative import beyond toplevel package

from project.lib import global_stuff

Работает, но я действительно не хочу быть застрял с использованием самого названия проекта в им порт.

Есть ли способ решить это, не используя имя проекта в импорте или изменить целую идею lib.

Или есть ли другая хорошая практика для хранения основной части кода?

источник

2012-05-05 xeor

Вы уверены, что в каждом каталоге есть '__init __. Py'? Вы помещаете «/ path/to/project» в свой PYTHONPATH? – rantanplan

Да, в каждом каталоге есть __init__.py, а первая запись в sys.path - это каталог проекта. – xeor

Вы правильно, что не хочет, чтобы связать имя проекта с импортом, так что общий шаблон для этого:

project/ 
    |__/source/ 
    |  |__/lib/ 
    |  |__/app/ 
    |__/deployment/ # code for your production deployment maybe 
    | 
    |__/docs/ 
    |__/tests/ 
    |__README 
    |__requirements.txt

и положить/путь/к/проект внутри ваших путей на вашем virtualenv (вы используете virtualenv правильно?).

Затем вы можете сделать внутри кода

from source.lib.blah import foo 
from source.app.baz import bar

EDIT: Это только оптимальным, если вы не отпускают код с открытым исходным кодом, конечно.Только когда у вас есть внутренний проект, в котором руководство продолжает изменять название проекта: D

источник

2012-05-05 13:00:25 rantanplan

Да, virtualenv и heroku и структура, на которую вы указали. Но вместо того, чтобы вызвать источник каталогов, я назвал его самим именем проекта. Может быть, я просто переименую его. – xeor

Надеюсь, вы прочитали мое редактирование! Если вы планируете выпустить его в сообществе, лучше придерживаться названия проекта! Представьте, что кто-то имеет ваш проект в качестве стороннего приложения и делает «из исходного импорта blah». Не хорошо :) – rantanplan

Да, я прочитал его, и «к счастью» я не могу опубликовать это как проект с открытым исходным кодом. «источник» как имя выглядит немного неправильным для меня, однако, но очень полезным. Дайте мне знать, если вы придумаете лучшее имя :) – xeor

Я действительно не хочу быть застрял с использованием самого названия проекта в импорте

Почему нет? Это лучший способ. Обратите внимание, что «относительный импорт для внутрипакетного импорта сильно обескуражен», - как said in PEP-8.

источник

2012-05-05 12:23:41 DrTyrsa

Я хочу, чтобы он был как можно более переносимым, даже при переименовании проекта. Вот почему я вижу использование имени проекта в импорте в качестве последнего средства. – xeor

@xeor Если вы хотите, чтобы приложение было портативным, вы не можете полагаться на данные проекта. Переместите 'global_stuff' в папку приложения или создайте еще одно приложение« global_stuff »и добавьте' requirements.txt'. – DrTyrsa

Создано основное приложение :) Спасибо за идею – xeor

глобальный/приложение Lib папки импорта в Django

ответ

Смежные вопросы