потому и бампают мажор во все поля

у них каждое обновление мажорное с поломкой API?

160412 23:04:11 <dstufft> pip jumped from 1.5 to 6.0 160412 23:04:26 <dstufft> because we just dropped the leading 1., because it didn't mean anything 160412 23:04:33 <Zart> still dont know what they tried to match... debian? 160412 23:05:38 <Zart> yeah, going from 1.5 to 6.0 instead of 1.6 makes perfect sense since "1 doesnt mean anything". 160412 23:05:56 <Zart> wait, what? 160412 23:06:40 <dstufft> we were never going to do a massive break-the-world 2.0, just going 1.9 -> 2.0 is kinda meh, because at that point the first digit is basically meaningless then as far as semantics go, and just going 1.10, 1.11, 1.12, etc what's the point of the leading 1. if it's always going to be 1. and it's never going to change 160412 23:07:40 <dstufft> versions numbers exist to communicate with people, we weren't using the most significant part of our version number to do anything, it was either always going to be 1.0, or it was just going to be something else because it "rolled over" 160412 23:07:44 <Zart> there were some 2.x releases back then if i'm not mistaken.. 160412 23:08:14 <Zart> or maybe that was distribute 160412 23:08:19 <dstufft> not of pip no, maybe of distribute 160412 23:08:29 <Zart> probably distribute 160412 23:08:57 <dstufft> setuptools version numbers are a combination of a strict adherence to semver and a release-early-release-often mindset 160412 23:10:23 <Zart> setuptools of that era had to deal with the zoo of version schemes... when 0.123alpha and 1.23-pre1 were a thing 160412 23:10:44 <Zart> thanks to tarek we got this crap sorted out 160412 23:12:15 <dstufft> heh, setuptools has been using a version routine that supported all of those things until just recently actually 160412 23:13:21 <dstufft> little over a year ago is when a setuptools that had improved version support got released 160412 23:13:37 <dstufft> (Setuptools 8.0 fwiw) 160412 23:15:10 <Zart> this all shows just how hard it's to implement network-enabled recursive unzip ;)

короче пацанов задолбало делать 1.х релизы и они решили клепать х.0 релизы 8)

"<dstufft> we were never going to do a massive break-the-world 2.0" т.е. апи фактически заморожен

видать слава Хрома не даёт покоя)

с учетом тыщ пакетов в мире, это уже и невозможно

Хей йоу. Пацаны

Сходу вопрос. Как в СА добавить колонку в таблицу или таблицу в бд не снося бд и не обращаясь в терминал?

альтер колумн чтоль?

В доке не нашел

Там чисто сносить бд, переиначивать классы таблиц

http://docs.sqlalchemy.org/en/latest/core/metadata.html#altering-schemas-through-migrations в доке

вут?

Все. Молчу

Спасибо

в общем тебе никто не мешает запилить альтер вручную

Иногда тупость нападает

но если хочешь кошерно - то sqlalchemy-migrate

Мне надо поставить релейшншип с ссылкой на другую таблицу

эм

но если хочешь кошерно - то sqlalchemy-migrate

Разве Alembic не лучше?

а как это относится к?

а, алембик же новее, да

Через консоль разве могу?

таки лучше, угу. у него с версиями клёвее

какую консоль?

Терминал

у тебя вопрос изначально был про ДДЛ но если речь про рилейшены на уровне свойств питонообъектов - то тут возможно не обязательно менять схему бд

Name.produceny.name

что терминал?

— петька, приборы? — 42! — что "42"? — а что "приборы"?!

Ничего. Чтоб вот такого рода установить связь мог установить через терминал линукса

Т.е. смогу ли я поставить через терминал такой релейшн в СА?

ШТА?

я спрашивал, дональд сказал что они используют модель строгих семантических версий

Проблема не в нумерации, а в том что "как на ракете". Я уже не раз видел что они в пределах трёх версий успевают удалить/переделать какой то функционал, а потом вернуть назад всё как было. Зачем вот так было торопится - не понятно.

смешались люди, кони... команды sql можно скармливать либо программам клиентам (как mysql, psql, isql, osql, sqlplus), так и полновесным гуевым тулзам (smss, toad, mysql workbench, phpmyadmin, и т.д.) либо в питоне, через вызовы либ... причем тут консоль/терминал?

блииин

можно обновить 2.6 питон до 2.7?

в центосе?

не ставить второй питон

Надо срочно расширить, допустим, бд

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

в центосе?

Надо сбоку ставить

Проблема не в нумерации, а в том что "как на ракете". Я уже не раз видел что они в пределах трёх версий успевают удалить/переделать какой то функционал, а потом вернуть назад всё как было. Зачем вот так было торопится - не понятно.

а до этого несколько лет было полтора релиза, потому что мейнтенер был сильно занят другим, изза чего сетаптулзы и форкнули в дистрибут. выбирайте крайность по душе, типа 8)

Системыне скрипты скорее всего запилены под 2.6

Ладно. Ознакомлюсь с докой

можно обновить 2.6 питон до 2.7?

не надо, если только не хочешь наебнуть систему

Покрайней мере у нас стоит 2.7 сбоку

ставь нужный из епел

а для стека джанга+нжинкс надо джангу ставить так или лучше в virtualenv?

а для стека джанга+нжинкс надо джангу ставить так или лучше в virtualenv?

как тебе удобнее

джанге и нгинксу похер

правда нгинксу вообще на всё похер, он только байты перекладывать умеет

а для стека джанга+нжинкс надо джангу ставить так или лучше в virtualenv?

Если у тебя возникают такие вопросы, то делай как написано в тутуриале на сайте джанги

Если у тебя возникают такие вопросы, то делай как написано в тутуриале на сайте джанги

да просто везде виртуаленв в основном

в манах

да просто везде виртуаленв в основном

потому что он предоставляет изоляцию от системы в случае например с докером, виртуаленв не нужен

потому что он предоставляет изоляцию от системы в случае например с докером, виртуаленв не нужен

так, тогда надо с виртуаленв

да просто везде виртуаленв в основном

Ну это потому что в большинстве случаев разработчик имеет на своей машине или на сервере ещё парочку легаси проектов, которым нужны другие версии питонячих либ. Если у тебя нет ни одного проекта - и ты только начинаешь, то можешь и в систему запилить, позднее выпилишь.

новички обычно юзают дерьмовые туториалы вида "sudo pip install foo"

Ага

pip install django DEPRECATION: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of pip will drop support for Python 2.6 Requirement already satisfied (use —upgrade to upgrade): django in ./lib/python2.6/site-packages

все равно в 2.6 лезет

я вот вообще pip не использую ?

обосрут полсистемы кодом, про который не знает менеджер пакетов, потом добавят еще всяких апт-гет инсталлов к этой вакханалии, смешают с setup.py develop, поимеют неведомую хуйню в виде ошибок неймспейс пакаджей, а убрать эти авгиевы конюшни уже поздно - проще всю систему с нуля переставить

ERROR: S client not available

я вот вообще pip не использую ?

билдаут?

ага

охуительная штука, но только сделали слишком топорно... он слишком тормозной из коробки, его передизайнить чуток надо, чтобы быстрее распаковывал

кстати, а почему нельзя судо пип ?

чтобы не пипнуть дрянь какуюто?

в итоге пипом выходит резко быстрее переставлять

кстати, а почему нельзя судо пип ?

судо пип поставит тебе в /usr/lib/pythonX.Y/site-packages (дист-пакаджи в дебиан-бейсед) туда, где уже стоят системные пакеты

охуительная штука, но только сделали слишком топорно... он слишком тормозной из коробки, его передизайнить чуток надо, чтобы быстрее распаковывал

Эм, ну установку пакетов из pypi наверное по другому не ускорить - она ведь самая тормозная в нём. Тут даже гольный pip + req.txt быстрее не справится. Надо просто настраивать по дефолту общий кеш egg-ов, фиксить версии в versions.cfg - и тогда билдаут быстро работает, т.к. не надо ставить то что уже поставленно и не надо чекать новые версии в PyPi

судо пип поставит тебе в /usr/lib/pythonX.Y/site-packages (дист-пакаджи в дебиан-бейсед) туда, где уже стоят системные пакеты

черт, всегда так делал

так, спс всем. встал джанга

Эм, ну установку пакетов из pypi наверное по другому не ускорить - она ведь самая тормозная в нём. Тут даже гольный pip + req.txt быстрее не справится. Надо просто настраивать по дефолту общий кеш egg-ов, фиксить версии в versions.cfg - и тогда билдаут быстро работает, т.к. не надо ставить то что уже поставленно и не надо чекать новые версии в PyPi

ты видел что пип нынче делает?

у него встал (ц)

ты видел что пип нынче делает?

Нет, неужели он распараллеливает установку req.txt?

Ну и как бы тут не только дело в скорости - меня она устраиват, т.к. установить все зависимости - это одноразовая операция, дальше только еденичные обновления. Кроме этого билдаут делает ещё полезных штук, которые pip не делает (да и не должен делать)

Нет, неужели он распараллеливает установку req.txt?

не... сперва он качает указанные пререки, потом опрашивает их депенды и скачивает всё рекурсивно, не устанавливая (в отличие от изи/билдаута, которые чередуют всё сразу) даунлоады кэшируются теперь автоматом, и если есть в кэше - берется сразу локальная копия далее идёт фаза установки - пип запускает setup.py bdist_wheel и кэширует готовое колесо после чего ставит либо из колеса, либо если бдист зафейлил, то пробует через сетап инсталл на повторных установках ставит сразу колёса, что есть тупая распаковка зипа

ну да, билдаут охуителен рецептами, а не инсталлятором

не... сперва он качает указанные пререки, потом опрашивает их депенды и скачивает всё рекурсивно, не устанавливая (в отличие от изи/билдаута, которые чередуют всё сразу) даунлоады кэшируются теперь автоматом, и если есть в кэше - берется сразу локальная копия далее идёт фаза установки - пип запускает setup.py bdist_wheel и кэширует готовое колесо после чего ставит либо из колеса, либо если бдист зафейлил, то пробует через сетап инсталл на повторных установках ставит сразу колёса, что есть тупая распаковка зипа

Хм, тоже самое можно в билдауте настроить. Т.е. можно указать папку для кеширования скачаных файлов, и папку для уже установленых egg-ов. Первое я не делаю, т.к. нет смысла при наличии второго. Разве что под разные версии питона если придётся ставить один и тот же пакет - но это редко бывает.

не. билдаут (до 2й версии) использовал несколько иной подход

Ну опция eggs-directory там всегда была

он вместо колёс собирал яйца, а потом генерировал обвязочные скрипты где прописывались пути к каждому в sys.path

Вот такое у меня прописано в ~/.buildout/default.cfg [buildout] eggs-directory = /home/cykooz/PycharmProjects/buildout-eggs Все мои проекты юзают эту папку для кеша яиц

с одной стороны это позволяло менять набор версий простым изменением маленького файлика

с другой тормозило импорты как пиздец изза раздутого sys.path и хуевой тучи стат() вызовов на файлуху

с другой тормозило импорты как пиздец изза раздутого sys.path и хуевой тучи стат() вызовов на файлуху

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

в итоге пип, который на каждый инсталл распаковывает зипы оказывается заметно шустрее билдаута, который просто меняет скрипт-обвязку 8\

в общем это к тому, что пора валить с z3c.recipe.egg

Не, про инсталл мы вроде выяснили - билдаут также и делает

альтернативные рецепты с пипом есть, но я не тестил 8(

стандартный z3c.recipe.eggs ставит яйца а они радикально отличаются от колёс

То что билдаут генерит скрипты с прописыванием в sys.path всех записимостей - это его основная фича, которая в большинстве случаев позволяет обойтись без virtualenv. Как её заоптимизировать - фиг знает

стандартный z3c.recipe.eggs ставит яйца а они радикально отличаются от колёс

В установленном виде уже пофиг на отличия. Оно просто установленно и ничего больше делать не требуется с ним.

То что билдаут генерит скрипты с прописыванием в sys.path всех записимостей - это его основная фича, которая в большинстве случаев позволяет обойтись без virtualenv. Как её заоптимизировать - фиг знает

есть рецепты которые собирают яйца в кучу.. eggbasket или как-то так