в смысле, внутри компании

а ну епта

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

http://amureki.me/how-github-uses-github-to-deploy-github.html

вот тут по английски кратко описывал

они там, конечно, повернутые, но прикольно

а по-моему, круто и умницы

да, я в хорошем смысле имел в виду :)

слайды хотел залить, но там пдфка на 16 мб, думаю, ругаться будут)

Что в качестве CI используете, господа?

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

прям завидую чёрной завистью, в берлине было дело?

угу

когда ещё такие конторы придут митапиться в питере

Что в качестве CI используете, господа?

travis circleci gitlabci

(люблю тревис, но дорогой)

travis circleci gitlabci

всё то же, разве что кроме трэвиса дженкинс

а че не jenkins например? он в AppAnnie используется - не знаю почему

можно и дженкинс :) лишь бы работу свою выполнял

и укладывался в вашу инфраструктуру

один седой девопс сказал мне что ci все отвратительны

нет хороших

у того же дженкинса интерфейс делали для инопланетян

и триггеры до сих пор берут и слетают рандомно. На последней версии. Это ж вообще никуда не годится.

ну и джава, конечно.

?

ой, как-то я вбросил почти в роли зарта

простите

без мата несчитово

?

Да, надо бы circle посмотреть. Честно говоря gitlab CI уже вполне неплох

Вот прямо пока с ним даже не хочется свой пока пилить. А уже хотелось...

Вот скажем есть у вас 2 проекта. 1) Админка на джанге 2) API на Django Rest Framework И есть конечно какая-то общая среди них часть. Как вы организуете такой код?

Да, надо бы circle посмотреть. Честно говоря gitlab CI уже вполне неплох

из того, с чем имел дел, самый приятный был

как назло два последних проекта не терпели облаков и хостились сугубо на железе

(я про сёркл-сиай)

(я про сёркл-сиай)

А я думал оно on promise умеет

Тогда да, не интересно, остается gitlab и Jenkins, я то не слышал чтобы последнего за функциональность ругали. А интерфейс там, да, из параллельной вселенной с другими законами физики

teamcity еще есть :)

А я думал оно on promise умеет

enterprise тариф умеет

Тогда да, не интересно, остается gitlab и Jenkins, я то не слышал чтобы последнего за функциональность ругали. А интерфейс там, да, из параллельной вселенной с другими законами физики

гитлаб ещё ребёнок

но растёт быстро

Вот скажем есть у вас 2 проекта. 1) Админка на джанге 2) API на Django Rest Framework И есть конечно какая-то общая среди них часть. Как вы организуете такой код?

ну вот можно положить все в одну репу в папки условно api django common можно 3 репы иметь и вычекивать их так же можно 3 репы и общую держать на как submodule и всякие другие варианты, да?

кто как поступает?

ой, как-то я вбросил почти в роли зарта

зарт жабу тоже не жалует

ну вот можно положить все в одну репу в папки условно api django common можно 3 репы иметь и вычекивать их так же можно 3 репы и общую держать на как submodule и всякие другие варианты, да?

не сталкивался с таким кейсом, честно говоря

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

не сталкивался с таким кейсом, честно говоря

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

ну вот можно положить все в одну репу в папки условно api django common можно 3 репы иметь и вычекивать их так же можно 3 репы и общую держать на как submodule и всякие другие варианты, да?

если код можно юзать отдельно от другого проекта - отдельной репой, если нет - разнести по пакаджам

вот что значит по пакаджам?

каталог+__инит__

я пока сделал 3 папки в одной репе api django shared и установил PYTHONPATH=корень

ну кстати да, я бы тупо оставил всё в одной репе

пока это не вызывает явных неудобств

вроде неудобств при докеризации

учитесь питонопакаджингу

вечно джанга с этим в проёбе

я пока сделал 3 папки в одной репе api django shared и установил PYTHONPATH=корень

но зачем трогать питонпатх?

но зачем трогать питонпатх?

а как импортить?

оформить все пакетами по-человечьи и вписать в инсталл наравне с прочими

оформить все пакетами по-человечьи и вписать в инсталл наравне с прочими

не понимаю. и pip install делать?

ставить пипом, как джангу и ко

там же код живой, меняется. каждый раз ставить?

да, в чем проблема

-e

что -e?

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

pip install -e .

я не понимаю тезис про учиться

ERROR: S client not available

что нужно изучить

я поменял строчку кода и должен запутстить pip install?

нет

учить создание пакетов питона

не понимаю :)

я не могу нормально писать со сраной мобилы 8/

я не могу нормально писать со сраной мобилы 8/

теперь понимаю))

на про пакеты все еще не понимаю

я поменял строчку кода и должен запутстить pip install?

@andreyzakharevich как нужно делать?

ну вот зарт тебе говорит, что есть опция, которая устанавливает тебе пакет в режиме разработки. то есть он не в site-packages будет лежать, а там, где ты код пишешь

-e = --editable путь к коду впиливается в сис.патх и становится импортабельным. там редактируй сколько влезет

о! это хорошая новость

спасибо

ну и да, просто почитай про setuptools, там все написано

раньше это делали через python setup.py develop

сейчас лучше про это забыть 8(

сейчас это в третьем питоне?

сейчас - это после перехода на хренов пип

хм. у меня вроде в virtualenv'е работало. питон второй если что

работает. но есть один нюанс (с)

на доклад тянет ;Р

-e = --editable путь к коду впиливается в сис.патх и становится импортабельным. там редактируй сколько влезет

Для разработки супер. А что делать правильно при деплое на прод?

собирать wheel и устанавливать из него. или прямо из гитхаба если хочется ощущений

собирать wheel и устанавливать из него. или прямо из гитхаба если хочется ощущений

спасибо, изучу

Для разработки супер. А что делать правильно при деплое на прод?

делать бдисты/колёса же

для азов изучать почти нечего

да я понимаю что там нету rocket science :D

уф

добрался домой и до ноута

герой))) ты много написал с телефона. не каждый сможет))

в общем для нормального деплоя на pypi, в продакшен или куда угодно - надо оформлять код в виде distribution

терминология: в питоне есть скрипты - то, что запускается непосредственно питоном, например python setup.py ... скрипты в общем случае могут иметь какие угодно имена/расширения, содержать произвольные символы (хоть пробелы, хоть точки) но традиционно юзают расширение .py, для гуи скриптов предусмотрено расширение .pyw, для активскрипт движка применяется .pys по мере того как язык развивался, понадобилось создавать более сложные конструкции, и тогда были добавлены импорты, которые работали с двумя видами сущностей: модули - исходные файлы на питоне с расширением .py пакаджи - каталоги, содержащие модуль __init__, и другие пакаджи/модули