2017-10-06 3 views
0

私は、site-packagesの下にディレクトリ構造を既に設定した別のpythonパッケージの一部になりたいモジュール/ファイルを配布しようとしています。 site-packagesの下で与えられた構造のためにPython:setuptoolsを使って別のパッケージにファイル/モジュールを配布する

-- main_package 
    -- __init__.py 
    -- sub_package 
     -- __init__.py 
     -- bar.py 

私は両方のパッケージsub_packageの下で、私はモジュールbar.pyの隣に存在するモジュールfoo.pyを持っています。典型的なパッケージのラインに沿って私のレポの構造をセットアップした場合、main_packagesub_packageの既存の__init__.pyファイルをcluberする必要がある__init__.pyがsetuptoolsに必要です。理想的には、これは私たち自身のピピから配信されるホイールまたはsdistになります。

私はpy_moduleを試してみましたが、サイトパッケージの最上位以外にモジュールを置くことはできません。

具体的には、saltstack external_pillarを塩で設定したsalt/pillar/structureに配布しようとしています。 external_pillarが必要な場合もあればそうでない可能性がある複数のsaltインスタンスがあるので、単純にピラールを私たちが持っている塩分布にまとめることは実現不可能です。

+0

なぜこのモジュールを既存のサイトパッケージディレクトリにインストールしますか?どのような行動が期待されますか? – FabienP

+0

私は 'import main_package.sub_package.foo'が動作すると期待しています – Silfheed

答えて

0

namespace packagesを探している可能性があります。このような構造あなたのケース付

`-- main_package 
    | # no __init__.py here 
    `-- sub_package 
     |-- __init__.py 
     `-- foo.py 

のPython 3.3は、それはネイティブの名前空間のパッケージを作成するために必要とされるすべてのPEP 420からの暗黙的な名前空間のパッケージを追加しましたあなただけの__init__.pyを省略していることです名前空間パッケージディレクトリ。

...

名前空間のパッケージを使用するすべての分布が__init__.pyを省略またはpkgutilスタイル__init__.pyを使用することが極めて重要です。配布がないと、名前空間のロジックが失敗し、他のサブパッケージはインポートできなくなります。

...

最後に、すべてのディストリビューションはsetup.pyでsetup()namespace_packages引数を指定する必要があります。

しかし、あなたの質問から私はsub_packageが既にmain_packageに存在するか否かを確認していません。

モジュールをシャドーイングしないで、構造体をsub_packageに拡張するために使用する構造が不明な場合は、これを行うために別のサブパッケージ名を使用する必要があります。

+0

" site-packagesの下の与えられた構造体の場合: "は' sub_packages'が既に存在することを意味します。あなたの例で 'sub_package'の' __init __。py'が与えられた 'sub_package'ディレクトリの' __init __。py'を上書きしてしまうので、この解決法はうまくいきません。 – Silfheed

+0

@ Silfheedの場合、興味のあるパッケージをフォークしてファイルを追加することができます。あるいはオリジナルのサブパッケージ__init__とmodulesとあなた自身の名前空間パッケージを作成します。しかし、ユーザーが何らかの方法で元のものとあなたのものを差別できるようにするのは明らかでしょう。したがって、若干異なる名前が良いものになる可能性があります。 – FabienP

関連する問題