Извините за стену с текстом, но я пытаюсь дать хороший фон для своего вопроса. На самом деле здесь миллион вопросов, потому что я совершенно запутался. Недавно я изучил программирование на Python и создал приложение для Windows. Теперь я хочу реализовать это приложение и несколько других идей для Ubuntu и выпустить их под лицензией GPL-3 с открытым исходным кодом. Хотя я хотел бы, чтобы код можно было запускать в любой системе (или, по крайней мере, в Ubuntu и Windows).

Чтобы узнать, как работает упаковка Ubuntu, я посмотрел на быстрое приложение, которое недавно использовалось в App Developer Showdown. Но структура папок и файлы, которые она создает, не имеют для меня никакого смысла. Итак, я прочитал Руководство по упаковке Ubuntu и Процесс проверки приложений со всеми содержащимися там ссылками, а также Политику Debian Python . Но весь этот текст просто работал, чтобы меня больше запутать в быстром создании файлов и папок.

Быстрый способ?

Итак, вот что я понял из быстрого (при условии, что имя моего проекта - proj):

proj / bin = один единственный файл, который будет скопирован в / usr / share / bin / proj.py, чтобы разрешить запуск приложения с глобального пути? Но это было бы нарушением правил «процесса проверки приложений», верно?
proj / data / * = файлы, которые должны находиться в / usr / share / proj / *, верно? Но это также было бы нарушением правил «Процесс проверки приложений»?
proj / help / C / * = некоторая документация HTML, я думаю, которая должна находиться в / usr / share / doc / proj / и это хорошо работает с «Процессом обзора приложений», но почему папка называется «C», а не просто «proj»?
proj / tests / = какие-то файлы для «тестового» пакета в Python . Я думаю, это здорово, с нетерпением жду возможности узнать, что это такое.
proj / proj / = некоторые файлы, которые кажутся связанными с новыми файлами в папке proj_lib? Кажется ненужным, и я вообще не понимаю, зачем они здесь.
proj / proj_lib / = фактический исходный код, я полагаю?

Затем быстро также создает proj / apport и proj / etc / apport * , которые я понятия не имею, что они делают и почему они добавлены.

Теперь, что действительно сбивает с толку, это файловая структура. Похоже, я ничего раньше не видел. И, честно говоря, выглядит очень излишне сложным. Ниже в этом разделе я опишу способ создания собственной файловой структуры проекта, что может помочь объяснить, почему это меня так сбивает с толку. Но во-первых, мое понимание быстрого пути (обратите внимание, что мое понимание может быть неверным на данном этапе).

Прежде всего, setup.py .Этот файл содержит функцию update_config (), которая просто загружает другой файл с именем proj / proj_lib / projconfig.py. Но этот файл config.py, похоже, не содержит ничего, что было бы полезно хранить отдельно от setup.py? На самом деле, есть много вещей, которые я никогда раньше не видел, чтобы кто-то предлагал поместить их в файл setup.py. Setup.py также содержит жестко закодированное имя файла, указывающее на значок SVG, а в противном случае просто копирует файл desktop.in на себя, так почему бы просто не внести изменения непосредственно в файл desktop.in без этой функции в настройке .py? Затем есть еще одна функция для создания подкаталога proj / data / share / proj и копирования туда файла desktop.in, назначение которого я не понимаю? Зачем нужна функция, которая делает это, если изначально вы можете просто сохранить файл? Затем после всего этого бессмысленного кода появляется что-то, что на самом деле выглядит как обычный setup.py.

Теперь proj / bin / proj.py , который, как я полагаю, предполагается использовать для запуска приложения? Это просто похоже на переназначение / usr / на /opt/extras.ubuntu.com/ в ранее необъявленной переменной syspath. Полагаю, это сделано для того, чтобы учесть правила в «Процессе проверки приложений» для приложений, которые используют стандартные имена папок для всех других разновидностей 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 / содержит все мои файлы .ui, созданные с помощью Qt Designer.

Остальные папки предназначены только для хранения некоторых файлов, которые заставят приложение работать в пакете с py2exe для Windows. По сути, это файлы, которые будут предоставляться через зависимости в Ubuntu.

Обратите внимание, что эта установка отлично подходит для разработки под Windows. Я использую py2exe для создания исполняемого файла, который попадает в папку proj / dist / , и я могу просто скопировать файлы в эту папку, и он будет работать на любой машине Windows.

Как мне это совместить?

Я потратил несколько дней, пытаясь прочитать документацию. Я вряд ли что-нибудь смогу быстро найти, кроме базового руководства и материалов на мастер-классах App Developer Showdown. Я не могу найти там ничего, что помогло бы мне быстро разобраться в структуре папок, предложенной.

Из того, что я прочитал, я мог бы использовать os.environ ['HOME'] , чтобы создать путь к ~ / .config / proj.conf в Ubuntu или C: / Users / username /. config / proj.conf в Windows. Пока я могу продолжать кросс-платформенный код. Но затем с разделением на / bin и / etc и / opt я начну сталкиваться с некоторыми проблемами.Конечно, я мог бы в крайнем случае сохранить две копии кода - одну для Ubuntu и одну для Windows. Но тогда мне все равно нужна аналогичная структура папок, чтобы упростить перенос изменений кода.

Должен быть кто-то, у кого уже есть хорошее решение для этого. И, возможно, этот человек также мог бы (помимо того, что привести пример того, как сделать это кроссплатформенным) описать, почему существует такая длинная цепочка файлов, вызывающая другие файлы, вызывающие другие файлы в быстрой настройке по умолчанию? Конечно, теперь я предполагаю, что быстро использует какую-то рекомендованную модель для Ubuntu. Если это не так, я хотел бы получить предложения о рекомендуемой структуре папок для распространения приложения через репозитории Ubuntu?