psp (страницы сервера python) под mod_wsgi?

Есть ли способ запустить код .psp (страницы сервера Python) под apache + mod_wsgi? Пока мы движемся к более новым фреймворкам на основе wsgi, у нас все еще есть устаревший код, написанный на psp, который работает под mod_python.

Мы хотели бы иметь возможность запускать его на том же сервере, на котором размещен другой код Python на основе wsgi. Вкратце - есть ли способ поддерживать psp под mod_wsgi? Или есть какие-то другие хитрости, которые хотя бы позволяют mod_wsgi и mod_python нормально работать на одном сервере?

-S


person shreddd    schedule 27.01.2010    source источник
comment
ПСП!?!? (Гуглится) О, БЛЯДЬ! modpython.org/live/current/doc-html/pyapi- psp.html Зачем вам переносить ошибки PHP и ASP на Python? Это зло.   -  person Lennart Regebro    schedule 27.01.2010
comment
Проблема здесь в устаревшем коде. Хотя мы не хотим писать новый код для PSP, кое-что уже есть, и оно должно работать. Мы хотим писать новые приложения под Django, но до тех пор, пока устаревший код не будет перенесен, нам все еще нужно иметь возможность работать в режиме, в котором мы можем использовать как mod_python/psp, так и mod_wsgi/django.   -  person shreddd    schedule 28.01.2010


Ответы (1)


Нет, порта mod_python PSP для mod_wsgi нет.

Да, вы можете запускать mod_python и mod_wsgi на одном сервере, если оба используют одну и ту же версию Python и оба динамически связаны с библиотекой Python. Видеть:

http://code.google.com/p/modwsgi/wiki/InstallationIssues

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

person Graham Dumpleton    schedule 27.01.2010
comment
Разве запуск приложений WSGI в режиме демона не уменьшит проблемы с инициализацией? - person Ignacio Vazquez-Abrams; 27.01.2010
comment
Нет, процессы режима демона являются ответвлением родителя Apache, а не ответвлением/exec, как в FASTCGI. Таким образом, в FASTCGI нет полной изоляции. Будучи всего лишь форком, вы получаете и другие преимущества, например лучшую интеграцию с Apache и лучшее управление процессами. Таким образом, когда вы выигрываете в одной области, вы теряете в других. - person Graham Dumpleton; 27.01.2010
comment
Спасибо, Грэм, поиграю с двойной установкой и посмотрю, что получится. - person shreddd; 28.01.2010
comment
Как описано в ссылке, проблема заключалась в том, что mod_wsgi имел динамически связанный libpython и mod_python, у которого он был статически связан. Перекомпилировал mod_python для динамической связи с libpython, и теперь он работает. Спасибо еще раз. Еще одно замечание: mod_python по умолчанию не будет динамически связываться с libpython. Пришлось изменить сценарий настройки, чтобы все работало правильно. Необходимо изменить LDFLAGS=${LDFLAGS} -L${PyLIBPL} на LDFLAGS=${LDFLAGS} - person shreddd; 28.01.2010
comment
Последняя версия mod_wsgi явно вылетает, если загружается mod_python. Я пытался обойти это (в коде mod_wsgi), но он действительно больше не работает, поэтому mod_python и последний mod_wsgi являются взаимоисключающими. - person IanSR; 09.09.2011
comment
Невыпущенный код в репозитории исходного кода mod_wsgi не будет работать с одновременно загруженным mod_python. И да, это задумано, но почему вы используете еще не законченный mod_wsgi 4.0, а не официальный tar-шар mod_wsgi 3.3? FWIW, причина, по которой они больше не могут сосуществовать, заключается в том, что mod_wsgi пришлось удалить в нем хаки, чтобы компенсировать неработающее использование потока в mod_python. Если бы этого не было сделано, поддержка mod_wsgi Python 3.2 была бы крайне болезненной. Просто не стоило пытаться условно иметь два разных способа обработки потоков. - person Graham Dumpleton; 09.09.2011