web-dev-qa-db-ja.com

Python開発で共有モジュールを使用する適切な方法は何ですか？

私はチームの開発ツールスイートの一部としてPythonを採用することに取り組んでいます。使用する他の言語/ツールを使用して、作業に固有の多くの再利用可能な関数とクラスを開発します。これにより、作業方法が標準化され、車輪の再発明が大幅に削減されます。

これが通常Pythonでどのように処理されるかの例を見つけることはできないようです。現在、ローカルドライブに開発フォルダーがあり、その下に複数のプロジェクトフォルダーがあり、追加の「共通」フォルダーには、再利用可能なクラスと機能を持つパッケージとモジュールが含まれています。これらの「共通」モジュールは、複数のプロジェクト内のモジュールによってインポートされます。

Development/
    Common/
        Package_a/
        Package_b/
    Project1/
        Package1_1/
        Package1_2/
    Project2/
        Package2_1/
        Package2_2/

Pythonアプリケーションを配布する方法を学ぼうとすると、参照されるすべてのパッケージは最上位のプロジェクトフォルダーの下にあり、それに付随するものではないという仮定があるようです。おそらく正しいアプローチは、別のプロジェクトで共通/フレームワークモジュールを開発し、テストしたら、site-packagesフォルダーにインストールすることで各開発者の環境に展開することです。

誰でもこれに光を当てることができますか、この問題を議論するリソースを私に指摘できますか？

pythonpython-3.xdistutils
39
Steve Sawyer

複数のプロジェクトで共有したい共通のコードがある場合、このコードを物理的に別のプロジェクトに保存し、それを依存関係として他のプロジェクトにインポートすることを検討する価値があります。これは、共通のコードプロジェクトをgithubまたはbitbucketでホストし、pipを使用して他のプロジェクトにインストールできる場合に簡単に実現できます。このアプローチは、複数のプロジェクト間で共通のコードを簡単に共有できるようにするだけでなく、誤って悪い依存関係（つまり、共通コードから非共通コードに向けられた依存関係）を誤って作成するのを防ぐのにも役立ちます。

以下のリンクは、依存関係を管理するためにpipとvirtualenvを使用するための良い紹介です。あなたとあなたのチームがpythonまさにこの種の問題：

http://dabapps.com/blog/introduction-to-pip-and-virtualenv-python/

また、以下のリンクは、pipを使用してgithubから依存関係を取得する方法を示しています。

使用方法Python Githubからパッケージを取得するためのPipインストールソフトウェア？

10
robjohncox

この種のものに関する最初の必読事項は次のとおりです。

Pythonアプリケーション？ に最適なプロジェクト構造は何ですか？）==

あなたがそれを見なかった場合（そして2番目の答えのリンクをたどってください）。

重要なのは、各主要パッケージが「。」のようにインポート可能であることです。は最上位のディレクトリでした。つまり、サイトパッケージにインストールされたときにも正しく動作します。これが意味することは、次のように、主要なパッケージはすべてトップディレクトリ内ですべてフラットにする必要があるということです。

myproject-0.1/
    myproject/
        framework/
    packageA/
        sub_package_in_A/
            module.py
    packageB/
        ...

次に、あなた（他のパッケージ内）とユーザーの両方が次のようにインポートできます：

import myproject
import packageA.sub_package_in_A.module

等

つまり、@ MattAndersonのコメントについて一生懸命に考える必要がありますが、個別に配布可能なパッケージとして表示する場合は、最上位ディレクトリに配置する必要があります。

これは、あなた（またはあなたのユーザー）が以下を行うことを妨げるものではないことに注意してください。

import packageA.sub_package_in_A as sub_package_in_A

ただし、次のことは許可されません。

import sub_package_in_A

直接。

9
Ethan Coon

...参照されているすべてのパッケージは、それに付随するものではなく、最上位のプロジェクトフォルダーの下にあるという仮定があるようです。

これは主に、現在の作業ディレクトリが sys.path デフォルトでは、そのディレクトリの下のモジュールとパッケージをインポートするのが非常に便利です。

削除すると、現在の作業ディレクトリからものをインポートすることさえできません...

$ touch foo.py
$ python
>>> import sys
>>> del sys.path[0]
>>> import foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named foo

おそらく正しいアプローチは、別のプロジェクトで共通/フレームワークモジュールを開発し、テストしたら、site-packagesフォルダーにインストールして各開発者の環境に展開することだと思いました。

これは実際には開発の大きな問題ではありません。バージョン管理を使用しており、すべての開発者が同じ構造でソースツリーをチェックアウトする場合、環境変数をいじったりせずにコードが正しく動作することを保証するために、簡単に 相対パスハック を使用できますシンボリックリンク。

しかし、それはまた、再配布の問題を提起します。

ライブラリを使用するプロジェクトから独立してライブラリをリリースする場合、および/または複数のプロジェクトインストーラーが同じライブラリを共有する場合にのみ、事態はもう少し複雑になる可能性があります。その場合は、 distutils をご覧ください。

そうでない場合は、開発で使用したのと同じ相対パスハックを使用して、プロジェクトが「そのまま」動作することを確認できます。

3
Aya

これは、配布可能なpythonパッケージを作成するための最良のリファレンスだと思います：

ハッキングされたサイトにつながるリンクは削除されました。

また、すべてを単一のディレクトリの下にネストする必要があると感じないでください。次のようなことができます

platform/
    core/
        coremodule
    api/
        apimodule

そして、from platform.core import coremoduleなど.

2
Cameron Sparr