so be it the dependency exposure day

so be it the dependency exposure day

О ДАА!! Знаешь что еще? А слаке загрузка файлов не работает

:)

https://twitter.com/stuartthomas/status/836640721826365440

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

но в случае с #IoT надо просто дублировать главные функции в оффлайн всегда. Все у кого сейчас недоступно управление светом - ссзб

Попробую спросить тут: а возможно ли гццшный бэкенд собрать не пересобирая весь gcc?

но в случае с #IoT надо просто дублировать главные функции в оффлайн всегда. Все у кого сейчас недоступно управление светом - ссзб

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

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

а вот это прекрасно

https://twitter.com/BuzettiPlays/status/836648533256208385

во)

рабство 2.0

У кого-нибудь была необходимость сделать псевдонимы для аргументов в cli приложении? Мне надо было, чтобы, например, у аргумента --article-title был псевдоним --title . Ничего лучше не придумал, чем сделать так: p = argparse.ArgumentParser() g = p.add_mutually_exclusive_group() g.add_argument('--article-title', dest='article_title') g.add_argument('--title', dest='article_title') Вроде работает как надо p.parse_args(['--article-title', 'test1']) Namespace(article_title='test1') p.parse_args(['--title', 'test2']) Namespace(article_title='test2') Автоматически исключается возможность задать сразу оба аргумента. Не знаю, насколько это криво, но другого варианта для argparse не нашёл/не придумал.

hack for argparse adding subcommand aliases https://gist.github.com/sampsyo/471779

Вот такой костыль

Но выглядит так себе

У кого-нибудь была необходимость сделать псевдонимы для аргументов в cli приложении? Мне надо было, чтобы, например, у аргумента --article-title был псевдоним --title . Ничего лучше не придумал, чем сделать так: p = argparse.ArgumentParser() g = p.add_mutually_exclusive_group() g.add_argument('--article-title', dest='article_title') g.add_argument('--title', dest='article_title') Вроде работает как надо p.parse_args(['--article-title', 'test1']) Namespace(article_title='test1') p.parse_args(['--title', 'test2']) Namespace(article_title='test2') Автоматически исключается возможность задать сразу оба аргумента. Не знаю, насколько это криво, но другого варианта для argparse не нашёл/не придумал.

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

У кого-нибудь была необходимость сделать псевдонимы для аргументов в cli приложении? Мне надо было, чтобы, например, у аргумента --article-title был псевдоним --title . Ничего лучше не придумал, чем сделать так: p = argparse.ArgumentParser() g = p.add_mutually_exclusive_group() g.add_argument('--article-title', dest='article_title') g.add_argument('--title', dest='article_title') Вроде работает как надо p.parse_args(['--article-title', 'test1']) Namespace(article_title='test1') p.parse_args(['--title', 'test2']) Namespace(article_title='test2') Автоматически исключается возможность задать сразу оба аргумента. Не знаю, насколько это криво, но другого варианта для argparse не нашёл/не придумал.

click?

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

Да, там же можно было сколько хочешь вариантов, вроде

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

Да, там же можно было сколько хочешь вариантов, вроде

Именно

ну кроме что шорткатов

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

Ну, в голову приходит legacy, но тогда все равно один надо через deprecation warning проксировать.

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

Ещё вариант - поддержка чужого апи вместе со своим. При этом в своем стройно смотрится одно, но надо уметь и чужое, некрасивое.

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

Точно же, через запятую работает. parser.add_argument('--foo', '--bar', dest='arg') Только когда прочитал твой коммент, вспомнил, что так тоже можно. Я даже где-то такое видел, но совершенно вылетело из головы. Только в этом случае можно задать сразу все перечисленные аргументы, значение запишется из последнего. Нужно для поддержки legacy-интерфейса, да. Временно.

click?

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

Там можно указать куда положить. Дест кажется или мета

Fedora (Facebook) Python 3.6 is available now for Fedora. It will be in Fedora 26, or you can install the packages today on Fedora 24 or Fedora 25 link

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

ну или дайте где есть под 25-ю федору 3.6, а то на copr-е нет по ходу:(

Во время они:)

а анаконда еще не умеет в 3.6?

Коллеги, сейчас продумываем архитектуру будущего backend api. В связи с этим думаем, что можно использовать для этих целей: flask, falcon или bottle?

Или может быть есть какие-то более простые и изящные решения?

Или не главное, если в команде всем похеру, как у нас :D

Мне кажется, что это временно)

Мне кажется, что это временно)

Конечно, я такими темпами скоро буду другую работу искать...

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

pyenv

docker ?

А так да, pyenv ...

в докере дебажить не удобно

Обоснуй

gdb и править сырцы

Volumes?..

а смысл в докере при таком раскладе?

в докере дебажить не удобно

удобно, но это требует определённой привычки

я правлю сишники компилю их

а смысл в докере при таком раскладе?

окружение для разработки

Мне без разницы где делать py.test —pdb — в докере или нет.

либо wdb поднимать в отдельном контейнере, либо ipdb дружить с docker-compose, либо по сокету цепляться пайчармом свежим

я на всех вариантах жил

чем мне докер в этом поможет конкретно?

Просто либо у тебя virtualenv + docker, а так только докер

так

Мне не надо париться на тему того, чтобы держать virtualenv up-to-date

нет

мы сейчас не про py

ну в общем да, докер уже заменил собой венвы )

а про исходнки питона

А зачем тебе их компилировать?..

Мне не надо париться на тему того, чтобы держать virtualenv up-to-date

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

У меня два образа просто

А зачем тебе их компилировать?..

Ну это из серии зачем ты dotty ковыряешь. Просто по фану

Грубо говоря Dockefile.base: FROM python:3.6 RUN pip install -r requiemente.txt ONBUILD RUN pip install -r requirements.txt И Dockerfile: FROM sysradium/shit

ERROR: S client not available

Когда образ базовый сильно разъезжается с тем, что в requirements.txt и мне приходится много “доставлять” — делаю make upgrade_base

Который обновляет базовый образ в моем хабе

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

@mulga ну по фану ок … Я говорил работу :)

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

медленно же? Или ты кэшем решаешь эти вопросы

Если все целиком - медленно. Но оно кэшируется, если не меняешь requirement.txt, а если меняешь — да, медленно, но это редко

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

если зависимости не поменялись

Ты пересобираешь, но оно берет все из кэша

3.6 class Ololo: news: str

Я про docker-compose up -d —build api

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

Оно пересобирает все с нуля, если базовой образа нет с пакетами и поменялся requirements.txt — будет не очень быстро

Если не поменялся, то мгновенно, ибо кэш.

Ты пересобираешь, но оно берет все из кэша

так если оно всё берёт из кэша, зачем делить на два образа?

Незачем.

Только чтобы если ты добавил пакет тебе не пришлось долго ждать

Меня ж про это спросили :)

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

И это типа плюс. Если ты меняешь часто туда-сюда пакеты.

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

Грубо говоря Dockefile.base: FROM python:3.6 RUN pip install -r requiemente.txt ONBUILD RUN pip install -r requirements.txt И Dockerfile: FROM sysradium/shit

спасибо, то что надо )

не понимаю зачем так жить

не понимаю зачем так жить

сколько человек в команде backend/frontend (если это веб конечно) и сколько проектов?

проектов овер 9000

человек 3 - 7

что в данном контексте проект?

Коллеги, сейчас продумываем архитектуру будущего backend api. В связи с этим думаем, что можно использовать для этих целей: flask, falcon или bottle?

swagger, flask / eve, django / djangorestframework

наборы разных user-story как-то логически объединенных

наборы разных user-story как-то логически объединенных

ок, сколько приложений?

docker ?

из докера в IDE не видно пакетов. хотя, а можно же замапить volume... хм;)