質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.48%
Django

DjangoはPythonで書かれた、オープンソースウェブアプリケーションのフレームワークです。複雑なデータベースを扱うウェブサイトを開発する際に必要な労力を減らす為にデザインされました。

Q&A

解決済

2回答

13083閲覧

Djangoのユーザモジュールの配置場所について

al_aya_yuka

総合スコア98

Django

DjangoはPythonで書かれた、オープンソースウェブアプリケーションのフレームワークです。複雑なデータベースを扱うウェブサイトを開発する際に必要な労力を減らす為にデザインされました。

1グッド

3クリップ

投稿2015/01/13 10:46

いつも回答くださるエンジニア様にはお世話になっております。

Djangoで開発を行っているのですが、自作のライブラリなどはどのようなパスに置くのが良いのでしょうか。
※バッチがメインです
ドキュメントすべて洗ったわけではありませんがぱっと見、記述が見当たらなかったもので。。。

現在はアプリケーション共通のモジュール郡は

lang

1project/lib

アプリケーションごとにモジュール分けしているものについては

lang

1project/application/management/commands/lib

こんな感じで分けていています。
でもimportする際になんとなく「イケてない」感があるのです。

lang

1from lib.fugafuga import * 2from application.management.commands.lib.piyopiyo import *

もしかして、

lang

1project/application/management/commands/hogehoge.py

のバッチにひとまとまりになるよう詰め込むべきでしょうか?
モノによってはクラスが煩雑し、それこそ可読性を下げそうなのですが・・・

ご意見、そもそもマニュアルにあるなど有りましたらご教授ください。

hidehara👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

ベストアンサー

私の管理していたプロジェクトでDjangoを使用した時のルールは下記のようなものでした。
・複数アプリケーションで共通のモジュールはプロジェクトディレクトリ以下
・各アプリケーションでしか使用しないモジュールはアプリケーションディレクトリ以下

lang

1from application.management.commands.lib import *

としているところを見るとmanage.pyからのコマンド実行に関係するライブラリを格納していると想像しますが、このライブラリが実行コマンドからのみ参照されるのであれば問題ないと思います。

私が実装する場合は、上記のルールに従い下記のようにします。
ライブラリが参照される範囲を意識するとユニットテスト(tests.py)が書きやすいです。

lang

1# プロジェクト共通(settings.pyやurls.pyと同階層にlibディレクトリを作成する) 2from project.lib import hogehoge 3 4# アプリケーション共通(各アプリケーションのviews.pyと同階層にlibディレクトリを作成する) 5from application.lib import hugahuga

投稿2015/01/26 04:18

fsoe

総合スコア163

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

al_aya_yuka

2015/02/09 06:32

御返事遅くなりましたが、アドバイス有難うございます。 確かに、その方法がとてもスッキリしていると思います。 今後は参考にしてみたいと思います。
guest

0

お邪魔します。

pythonは何を差し置いても明示的で読みやすく間違いが起こりにくいようであることを大切にする言語です。
それなので、「別にイケてなくない」と思います。
ドメインが違う共通処理が違ったパッケージ階層のモジュールに配置されているのは当然のことです。
まあやろうと思えば色々とhackはできるのですが、醜いと思います。

どちらかというと

from lib.fugafuga import *
from application.management.commands.lib.piyopiyo import *

のように書かいていらっしゃるのですが、*で何をインポートしたか明示的でないことの方が問題視されると思われます。(使われているものが、どのソースに書かれているか一目でわかる、ということの方が重要だということ)

※個人的な雑感としてはapplication.management.commands.lib.piyopiyoは少し長いな、とは思いました。
application.lib.piyopiyoとかapplication.commands.piyopiyoとかのレベルでいいような気がします。そしてモジュール名を、管理用のバッチ処理だと明示的にわかるものにするのがいいかなと。

パッケージの分け方について参考になるもの、ですが、djangoには1.4からproject templateという仕組みがあります。
いろんな人がpypiやgit hubやbitbucketに自作project templateをあげていたりするので、
上記サイトで「django project template」と検索してみると、参考になるパッケージの分け方が見られるかもしれません。


(追記)
hackについてですが、醜い方法をひとつ例としてあげておきます。(笑)

lang

1# モジュールの呼び出し元に対してimportと同等の処理を実行させる 2# Aモジュールをインポートしたら、勝手にBモジュールもインポートされるようにする、というhack 3# 質問者さんのコードに合わせて、アスタリスクでのモジュールインポートを模倣 4import inspect 5import lib.fugafuga as module 6caller = inspect.getmodule(inspect.stack()[1][0]) 7for member in inspect.getmembers(module) 8 if(not member[0].startswith('_')): #アンダースコアから始まっているメンバは対象外 9 setattr(caller, member[0], member[1])

参考になれば幸いです。

投稿2015/01/15 17:24

ShinpeiYamamoto

総合スコア540

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

al_aya_yuka

2015/02/09 06:35

お返事遅れましてごめんなさい。 アドバイスありがとうございました。 import * については、簡略して記載してしまった結果です。 PEP8でも推奨されない書き方だったと思いますので、 実際に運用しているコードにはそのようなものはありません。 今後新しいコードを書くときは参考にさせていただきたいと思います。 ありがとうございました。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問