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

Итак, чтобы узнать, как работает упаковка Ubuntu, я посмотрел на приложение, быстро используемое в последнее время в App Developer Showdown. Но структура папок и создаваемые файлы не имеют для меня никакого смысла. Итак, я прочитал Руководство по пакетированию Ubuntu и процесс рассмотрения Applicaton со всеми ссылками, а также Политику 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/ также есть файл инициализации.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.

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

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

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

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