web-dev-qa-db-ja.com

Pythonアプリケーションのマルチプラットフォーム配布に適したフォルダー構造は何ですか？

テキストの壁については申し訳ありませんが、私の質問に良い背景を提供しようとしています。実際、私は完全に混乱しているため、100万の質問があります。最近、Pythonプログラミングを学び、Windowsアプリケーションを作成しました。Ubuntu用にそのアプリと他のいくつかのアイデアを実装し、オープンソースGPL-3としてリリースしたいと思います。コードを任意のシステム（または少なくともUbuntuとWindowsの両方）で実行できるようにします。

それで、Ubuntuパッケージングがどのように機能するかを知るために、私は最近App Developer Showdownで使用されている迅速なアプリケーションに注目しました。しかし、フォルダ構造とそれが作成するファイルは私にはまったく意味がありません。 buntu Packaging Guide と Applicaton Review Process をすべてのリンクとともに読み、 Debian Python =ポリシー 。しかし、これらのテキストはすべて、ファイルやフォルダーをすばやく作成する方法について混乱させるために機能しました。

すぐに？

だから、これは私がすぐに理解するものです（私のプロジェクト名がprojであると仮定して）：

proj/bin =グローバルパスからアプリを実行できるようにするために/usr/share/bin/proj.pyにコピーされる単一のファイルですか？しかし、それは「アプリケーションレビュープロセス」ルールに違反するでしょうか？
proj/data/* =/usr/share/proj/*の下にあるファイル、正しいですか？しかし、それは「申請審査プロセス」規則に違反することにもなりますか？
proj/help/C/* =いくつかのHTMLドキュメント、/ usr/share/doc/proj /の下にあるはずで、「Application Review Process」でうまく機能しますが、なぜフォルダ名は「C」ではなく「C」 「プロジェクト」？
proj/tests/ = Python内の「テスト」パッケージ用の何らかのファイル。これは素晴らしいことだと思います。それが何であるかを楽しみにしています。
proj/proj/ = proj_libフォルダー内の新しいファイルにリンクしているように見えるいくつかのファイル？不要なようです、そして、これらがなぜここにあるのか、私には理解できません。
proj/proj_lib/ =実際のソースコードだと思いますか？

その後、proj/apportとproj/etc/apport*もすばやく作成しますが、これらが何をするのか、なぜ追加されるのかはわかりません。

さて、本当に紛らわしい部分はファイル構造です。私が前に見たことがないように見えます。そして、正直に言うと、非常に不要に複雑に見えます。このセクションの下で、自分がプロジェクトファイル構造を作成する方法を説明します。しかし、最初に、迅速な方法の私の理解（この時点で私の理解が間違っている可能性があることに注意してください）。

まず、setup.py。このファイルには、proj/proj_lib/projconfig.pyという別のファイルをロードするupdate_config（）という関数が含まれています。しかし、そのconfig.py-fileには、setup.pyから分離しておくのに役立つ何かが含まれていないようです。実際、これまでにsetup.py-fileに配置することを提案する人はいませんでした。 setup.pyには、SVGアイコンを指すハードコード化されたファイル名も含まれています。それ以外の場合は、desktop.in-file自体をコピーするので、セットアップでこの関数を使用せずにdesktop.in-fileで直接変更を加えないでください。 .py？次に、サブディレクトリproj/data/share/projを作成し、そこにdesktop.in-fileをコピーする別の関数がありますが、その目的はわかりませんか？元々そこにファイルがあるだけで、それを行う機能があるのはなぜですか？ Thenこの無意味なコードはすべて、実際には通常のsetup.pyのように見えます。

ここで、アプリケーションを起動するために使用することになっていると思われるproj/bin/proj.py？これは、以前に宣言されていないsyspath変数で/ usr /を/opt/extras.ubuntu.com/に再マッピングするようです。だから、これは他のすべてのLinuxフレーバーに標準のフォルダー名を使用しているアプリの「アプリケーションレビュープロセス」のルールに対応するためだと思いますか？結構、理解できませんが、それで生きることはできます。このディレクトリの再マッピングの後、このファイルはproj/proj /init。pyを呼び出します。

proj/proj/__init__.pyは、モジュールの起動方法を定義する標準的な方法です。しかし、実際に何かを実行するコードを使用する代わりに、このファイルはさらに別のファイルにあるメインウィンドウクラスを実行します。

proj/proj_lib/には、init。py-ファイルもありますが、その目的はわかりません。次に、実際にアプリケーションの機能を含むように見えるWindow.pyがあり、ダイアログなどのような他のウィンドウpyファイルを呼び出します。

アプリのやり方

私のフォルダ構造は次のようになります。

proj/
proj/ui
proj/imageformats # necessary for imports to work
proj/sqldrivers   # necessary for imports to work

proj/フォルダーには、setup.pyと、アプリを起動するproj.pyがあります。私のproj.pyファイルには、すべてのメインウィンドウ機能があり、インポートを使用して他のいくつかのウィンドウと関数を呼び出し、このファイルの最後にmain（）アプリを起動する関数。

proj/ui/フォルダーには、Qt Designerで作成されたすべての.uiファイルが含まれています。

他のフォルダーは、Windowsのpy2exeでパッケージ化されたときにアプリケーションを動作させるいくつかのファイルを提供するためにあります。基本的に、これらはUbuntuの依存関係を通じて提供されるファイルです。

このセットアップは、Windows開発に最適です。 py2exeを使用して、proj/dist/フォルダーに終わる実行可能ファイルをビルドします。このフォルダー内のファイルをコピーするだけで、任意のWindowsマシンで動作します。

これをどのように組み合わせるのですか？

私は数日かけてドキュメントを読みました。基本的なチュートリアルとApp Developer Showdown Workshopsのものを除いて、すぐに見つけることができるものはほとんどありません。すぐに提案されたフォルダ構造を理解するのに役立つものはそこにありません。

私が読んだものから、os.environ['HOME']を使用して、Ubuntuでは〜/ .config/proj.confに、WindowsではC：/Users/username/.config/proj.confへのパスを作成できます。これまでのところ、プラットフォームコードをクロスし続けます。しかし、/ binと/ etcと/ optに分割すると、いくつかの問題が発生し始めます。もちろん、最後の手段として、コードのコピーを2つ保持できます。1つはUbuntu用にセットアップし、もう1つはWindows用にセットアップします。しかし、コードの変更を簡単に転送できるように、同様のフォルダー構造が必要です。

すでにこれに対する良い解決策を持っている人がいるはずです。そしておそらく、その人は、（クロスプラットフォームにする方法の例を与えることに加えて）デフォルトの迅速なセットアップで他のファイルを呼び出す他のファイルを呼び出すような長いチェーンがある理由を説明することもできますか？もちろん、私は現在、Ubuntuの推奨モデルをすばやく使用していると仮定しています。そうでない場合は、Ubuntuリポジトリを介してアプリケーションを配布するために推奨されるフォルダー構造を提案しますか？

application-developmentpythonquicklyprogrammingcrossplatform
4
GaRyu

Ubuntu固有のページまたはDebian固有のページ以外で多くのグーグル検索を行った結果、 this one が実際にかなり役立つことがわかりました。基本的に、提案は次のようにすることです。

proj/
proj/bin/proj.py                 # this will just "import proj" and "main()"
proj/proj/__init__.py            # this will just "import window.py" and run that
proj/proj/window.py              # main functionality
proj/proj/submodule/__init__.py  # import in window.py
proj/proj/test/                  # for that test package that quickly also uses
proj/README                      # basic readme file
proj/setup.py                    # standard distutils setup.py

これは、迅速な方法よりも私にとって賢明であり、元の方法に近いように思えます。そして、Ubuntuガイドラインに準拠したDebianパッケージにすることは不可能ではないでしょうか？だから私はすぐにものを消去してこれを行うと思います。誰もより良い提案がない限り？

ここに残っているのは、「WindowsだけでなくUbuntuにもうまくインストールするためにこれをどのように設定しますか？」、つまり、setup.pyを特別な方法でコーディングするか、コードで他の考慮事項を作成する必要があります...

4
GaRyu