장고 프로젝트 내에서 모듈을 가져 오기위한 제안 된 방법은 무엇입니까

Question

이것은 항상 저를 괴롭혔습니다. 그리고 저는이 일을하는 자신이 선호하는 방법을 실제로 생각해 내지 못했습니다.

장고 프로젝트에서 자신의 응용 프로그램 중 하나에서 무언가를 가져, 당신이 가져 수행

물론

from mymodule.model imoprt SomeModel 
from anotherone.model import AnotherModel 

, 하나 같이 작동합니다 :

from myproject.mymodule.model import SomeModel 
from myproject.anotherone.model import AnotherModel 

또는, 당신이해야 할 배포 할 때 PYTHONPATH을 올바르게 설정하면됩니다. 주어진 프로젝트 내에서 둘의 조합조차도 작동합니다.

두 번째 양식의 문제점은 utils.py 또는 그와 비슷한 것이 프로젝트에있는 경우입니다.

# This feels wrong 
import utils 

하지만, 저만있을 수 있습니다.

더 나은 이유는 무엇입니까?

Answer 1

내가 두 번째 대안을 사용하는 것이 좋습니다 것입니다 : 장고에서

from mymodule.model import SomeModel 
from anotherone.model import AnotherModel 

, 여러 프로젝트에 배포 수, 재사용 가능한 응용 프로그램을 작성하는 것이 좋습니다. 프로젝트의 이름을 지정하면 이러한 가능성을 저해 할 수 있습니다. 최상위 프로젝트 폴더의 이름을 변경하는 경우도 복잡합니다!

이것은 대부분의 장고 응용 프로그램에서 사용하는 전통입니다 (예 : pinax, django contrib 등).

자세한 내용은 DjangoCon 2008: Reusable Apps을 (를) 들어야합니다.

Answer 2

가능한 경우 절대 가져 오기를 사용하는 것을 선호합니다. 첫 번째 이유는 상대 수입이 Python 3에서 나간다는 것입니다. 따라서 습관에 빠지지 않는 것이 가장 좋습니다. (당신이 질문을 표현한 방식에 따라, 나는 당신이 프로젝트 패키지 안에 애플리케이션 패키지를 넣었다고 가정하고있다.) 두 번째 이유는 당신이 가져 오는 것의 의도를 더 명백하게 만든다는 것이다.

내 연습은 내 응용 프로그램 패키지를 프로젝트 패키지 안에 넣지 않는 것이지만. 이렇게하면 응용 프로그램을 이동하는 것이 더 쉬우 며 패키지 내에서 절대 가져 오기를 사용하는 경우 다른 응용 프로그램 내에서 동일한 응용 프로그램을 나중에 사용하면 다른 프로젝트를 반영하기 위해 모든 가져 오기를 다시 작성할 필요가 없습니다 이름.

Answer 3

어떻게 모듈을 정상적으로 패키지합니까? "myproject"모듈 아래에 모든 패키지를 패키징하는 경우 계속해야합니다. 그렇지 않다면 시작할 이유가 없습니다. Django 프로젝트에 있다는 것이이 질문과 관련이 있다는 것을 알지 못합니다. 코드를 재사용하지 않으면 패키지를 왜 분리해야합니까?

하지만 더 큰 요점은 더 넓은 의미에서 라이브러리를 패키지하고 배포하는 방법에 대해 생각하지 않는다는 것입니다. 그것들이 단지 유용한 유틸리티 루틴의 모음 일지라도 그것들을 공유하지 않으려는 경우에도 네임 스페이스 문제를 고려해야합니다. The Python Tutorial에는 개념에 대한 기본적인 기본 토론이 있습니다.