2009-12-07 2 views
8

Я создаю приложение Django, которое я с комфортом запускаю (тест :)) на хосте Ubuntu Linux. Я хотел бы упаковать приложение без исходного кода и распространить его на другую производственную машину. В идеале приложение может выполняться командой ./runapp, которая запускает сервер CherryPy, который запускает код python/django.Создание портативных приложений Django - нужна помощь

Я обнаружил несколько способов сделать это:

  1. распределяя .pyc файлы только и установку всех требований на целевой машине.
  2. Использование одного из многочисленных инструментов для упаковки приложений Python в распространяемый пакет.

Я действительно стреляю по опции nr.2, я хотел бы иметь приложение Django, поэтому его можно распространять без необходимости устанавливать или настраивать дополнительные вещи. Поиск в interwebs дал мне больше вопросов, чем ответов и очень кислый вкус, что упаковка Django - это тайное искусство, которое все знают, но никто не говорит. :)

Я пробовал замораживание (неудачно), Cx_freeze (простота установки не работает, версия репозитория работает, но выход приложения выходит из строя) и красный на dbuilder.py (который должен работать, но не работает действительно - я думаю). Если я правильно понимаю, большинство проблем возникает из-за того, что Django импортирует модули (пример), но я понятия не имею, как его решить.

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

+1

«без исходного кода» - почему? –

+0

Мне нужно отправить приложение на внешний, и я бы хотел, чтобы он не мог легко читать мой код. Я понимаю, что декомпилировать код python не очень сложно, но это труднее сделать, чем читать (и изменять) исходные файлы. – stricjux

+0

Чтобы продать клиентам, я бы предположил. – wisty

ответ

0

Параметр --noreload остановит автоматическое обнаружение Django, какие модули изменились. Я не знаю, исправит ли это, но может.

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

+0

Препятствует тому, чтобы мой код не был целью, но благодаря этой идее. Параметр --noreload не решает никаких проблем (я даже не могу запустить версию cx_freezed - см. Вывод: http://dpaste.com/129019/) – stricjux

+0

--noreload - это только вариант для построенного Django -in'ervererver 'и не будет применяться к PyCherry или любому другому веб-серверу. –

7

Я предлагаю вам основать свой дистрибутив на setuptools (инструмент, который улучшает стандартный дистрибутивный механизм Python distutils).

Используя setuptools, вы должны иметь возможность создавать яйцо Python, содержащее ваше приложение. Метаданные яйца могут содержать список зависимостей, которые будут автоматически установлены easy_install (могут включать Django + любые сторонние модули/пакеты, которые вы используете).

setuptools/distutils distros может включать в себя скрипты, которые будут установлены на /usr/bin, так что вы можете добавить свой сценарий runapp.

Если вы не знакомы с virtualenv, я предлагаю вам также взглянуть на это. Это способ создать изолированные среды Python, это будет очень полезно для тестирования вашего дистрибутива.

Вот блог с некоторой информацией о virtualenv, а также обсуждение нескольких других замечательных знать инструменты: Tools of the Modern Python Hacker: Virtualenv, Fabric and Pip

+0

Ссылка на инструменты кажется сломанной, есть ли альтернативный источник? – keppla

Смежные вопросы