Или если есть под двойку, то можно попробовать портировать. Да хотя бы тем же py2to3 пройтись и прочее. Ну сурово ждать — никто не сделает мне кажется.
Оооо, еще и с керберосом, ну удачи. Вообще можно ctypes попробовать просто либу ldap заюзать. Она точно умеет сама керберос, и скорее всего в скрипте об этом ломать голову не придется. По идее слабать необходимый сабсет возможностей можно быстрее чем за два месяца :)
Выносить настройки браузера в недра настроек ОС весьма странное решение. Конечно не вы первые, но блин — зачем? Так было в паре штук типа KDE, было жутко неудобно.
Нормально это оставить настройки прокси и в браузере и в недрах, уж если так хочется. Пусть меняют одни ключи реестра.
Ну как вам сказать — не очень полезная статья. Разбираться в сотнях команд — да кому оно надо. Плюс ко всему устанавливать вот так вот руками, а как потом обновлять и прочее? Кому сейчас эти панели вообще интересны.
Полезнее было бы обернуть всё это например в роли ansible, и в таком виде это уже была бы не очередная хавтушка, опасная для применения теми, кто на уровне применения хавтушек, а полезным проектом.
В общем отклика в сердцах вам не найти сейчас, спрячьте от греха, напишите что-нибудь более полезное. А то сейчас вы самоубийство на хабре получите :) Если оно вас конечно волнует.
Я аргументацию про зависимости принял, но не могу не посоветовать (не вам, а читающим) еще и opster. Click конечно больше плюшек имеет, но opster сильно меньше.
Огонь, проблема в том, что в вашем случае всё разлетится именно во время деплоя. Я такой подход не то чтобы не разделяю, у меня такой подход кончается увольнением персонажа.
А я прям боюсь спросить — не пофиг ли какая там версия питона в системе? Мне кажется это проблемы убунты, какая ей там версия нужна.
Программистам из ruby? ;) А с каких пор ubuntu у нас вдруг стала python-way? Пакетирование всего вся? А может яйца тоже надо пакетами ставить? Там вон даже хелперов пук есть ;) Предлагаю запакетировать весь сырный мир.
Ох йо, конечно проще идти скачать версию питона, развернуть ее, поиграться флагами configure. Или например собрать pypy, это еще интереснее, и согреться можно неплохо ноутом в процессе.
А тут выдумали — значит всё уже прописано у хитрых перцев в pyenv, иш, навыдумывали мозг себе не парить.
От моды просто наглухо, только мода тут ни при чем, чтобы мода это надо на Go срочно идти пилить и монадами присыпать. Даже нода уже не так жгет как в былые времена. Все меняется :)
Pundle решает несколько проблем — он прибивает гвоздями версию пакета во frozen.txt. Он подключает нужные версии пакетов для проекта просто по сладкой парочке файлов — requirements.txt и frozen.txt. И Pundle будет жутко ругаться если вписать пакет в requirements.txt и не запустить процедуру прибивания версии гвоздями.
А еще не будет ситуации как у меня сегодня, когда разработчик закинул код, а пакет не прописал. В случае pundle не прописав пакет, ты просто не сможешь его использовать. Это вам не гадить в virtualenv что попало, это по феншую великого пайтона и пророка его — не пропишешь, не получишь.
Замена виртуалэнв для разработки, а то все эти virtualenvwrapper это костыли поверх достаточно стремного решения которое не решает огромную тучу вопросов.
pyenv переключает нужную версию питона просто по файлу .pyenv-version в корне проекта. Например в нужном проекте сработает python2.7, в другом 3.4.1.
pyenv может легко поставить любую версию python, в том числе и последние свежие pypy и тому подобное.
То что его идея пришла из мира руби не делает её плохой.
Чуваки из дебиан немного странные и сломали easy_pip как-то раз, с совершенно тупой аргументацией. В итоге python -m venv пошел лесом.
Но учитывайте же, что это всё инструменты для удобной разработки — деплоить через pyenv я не рекомендую — при деплое вполне возможно воткнуть на сервер правильную версию интерпретатора с помощью какого-либо репо.
update_alternatives — ооочень странные рекомендации — нафига? В стартовом скрипте укажите полный путь до нужной версии, всё будет работать без этой фигни странной.
Вы почему то решили, что если работает как надо, то оно неявное и запутанное и магия. На самом деле оно просто менее муторное и исключает возможность наломать дров руками перебирая строчки в важном файле.
В Pundle нет магии, он прямой как стрела, он просто помогает разработчику точно трекать версии пакетов, на которых шла разработка.
И при чем тут руби магия кстати?
Ну и к venv я бы ваши два пункта не применял, вы его код не видели и вообще посмотрите в его внутренности.
Ну в продакшн тем не менее не надо ни первый ни второй — все таки лучше пакет собрать правильный под целевой дистрибутив. Тем более что их уже насобирали и они есть на любые версии ruby и под ubuntu и под centos/redhat.
Это я уточнил совет, а то ведь мужики просто сменят инструмент деплоя.
Ну в случае django может сработать, при другой схеме выставления версий может не прокатить.
Плюс все равно не гарантирует — разрабатываете и тестируете на одной версии, а на какой оно будет работать в production, неизвестно.
Еще не совсем понятно как быть с зависимостями. Всё это куча ручной работы, да к тому же не гарантирующей результат.
Плюс еще невнятные конструкции из кучи виртуалэнвов.
Это точно нормальное решение или мы, питоняшки, слишком не любим ничего менять?
pip кстати, насколько я помню, просто по site-packages с помощью pkg_resources прошвыривается и все пакеты которые нашел потом вот и выводит.
И есть несколько проектов которые нацелены именно на создание такого файлика с прибитыми зависимостями. Но мне мало, я хочу чтобы вообще всё всё всё само делалось! :)
Интересная штука — главное интересно зачем они компилят в django, jinja2 etc.
Нормально это оставить настройки прокси и в браузере и в недрах, уж если так хочется. Пусть меняют одни ключи реестра.
Полезнее было бы обернуть всё это например в роли ansible, и в таком виде это уже была бы не очередная хавтушка, опасная для применения теми, кто на уровне применения хавтушек, а полезным проектом.
В общем отклика в сердцах вам не найти сейчас, спрячьте от греха, напишите что-нибудь более полезное. А то сейчас вы самоубийство на хабре получите :) Если оно вас конечно волнует.
Программистам из ruby? ;) А с каких пор ubuntu у нас вдруг стала python-way? Пакетирование всего вся? А может яйца тоже надо пакетами ставить? Там вон даже хелперов пук есть ;) Предлагаю запакетировать весь сырный мир.
А тут выдумали — значит всё уже прописано у хитрых перцев в pyenv, иш, навыдумывали мозг себе не парить.
Pundle решает несколько проблем — он прибивает гвоздями версию пакета во frozen.txt. Он подключает нужные версии пакетов для проекта просто по сладкой парочке файлов — requirements.txt и frozen.txt. И Pundle будет жутко ругаться если вписать пакет в requirements.txt и не запустить процедуру прибивания версии гвоздями.
А еще не будет ситуации как у меня сегодня, когда разработчик закинул код, а пакет не прописал. В случае pundle не прописав пакет, ты просто не сможешь его использовать. Это вам не гадить в virtualenv что попало, это по феншую великого пайтона и пророка его — не пропишешь, не получишь.
Ах, да. Виртуалэнв становится ненужен.
github.com/Deepwalker/pundler
Замена виртуалэнв для разработки, а то все эти virtualenvwrapper это костыли поверх достаточно стремного решения которое не решает огромную тучу вопросов.
pyenv может легко поставить любую версию python, в том числе и последние свежие pypy и тому подобное.
То что его идея пришла из мира руби не делает её плохой.
Чуваки из дебиан немного странные и сломали easy_pip как-то раз, с совершенно тупой аргументацией. В итоге python -m venv пошел лесом.
Но учитывайте же, что это всё инструменты для удобной разработки — деплоить через pyenv я не рекомендую — при деплое вполне возможно воткнуть на сервер правильную версию интерпретатора с помощью какого-либо репо.
update_alternatives — ооочень странные рекомендации — нафига? В стартовом скрипте укажите полный путь до нужной версии, всё будет работать без этой фигни странной.
В Pundle нет магии, он прямой как стрела, он просто помогает разработчику точно трекать версии пакетов, на которых шла разработка.
И при чем тут руби магия кстати?
Ну и к venv я бы ваши два пункта не применял, вы его код не видели и вообще посмотрите в его внутренности.
Это я уточнил совет, а то ведь мужики просто сменят инструмент деплоя.
Плюс все равно не гарантирует — разрабатываете и тестируете на одной версии, а на какой оно будет работать в production, неизвестно.
Еще не совсем понятно как быть с зависимостями. Всё это куча ручной работы, да к тому же не гарантирующей результат.
Плюс еще невнятные конструкции из кучи виртуалэнвов.
Это точно нормальное решение или мы, питоняшки, слишком не любим ничего менять?
И есть несколько проектов которые нацелены именно на создание такого файлика с прибитыми зависимостями. Но мне мало, я хочу чтобы вообще всё всё всё само делалось! :)