В комментариях к той статье уже спрашивали, но повторюсь.
Есть ли примеры крупных проектов, реализованных на $mol? Ссылки на компании, которые попробовали его использовать для разработки новых приложений? Сравнение скорости разработки чего-то сложнее Hello world? Отзывы новичков о сложности вкатывания в новую технологию?
Если $mol такая прорывная технология, то что-то не видно, чтобы за нее бизнес проголосовал рублем. А у разработчиков она определенно не в почете, судя по комментариям к каждой статье про этот фреймворк.
давайте посмотрим на известный бенчмарк с набором данных в 50 Гб.
Потеряли ссылку на сам бенчмарк из оригинальной статьи: https://h2oai.github.io/db-benchmark/. Там хоть объясняется, что и как бенчмаркали.
Ну и в целом сравнение, где у всех остальных реализаций поголовно "out of memory", выглядит очень странно. Стоило бы сравнить на меньших объемах датасетов, чтобы хоть какие-то цифры были. Ну и "not implemented" у Spark выглядит смешно, уж groupBy и join там конечно есть.
Я пользуюсь вот этим скриптом для TamperMonkey, но он лишь позволяет скрыть определенные сайты из выдачи. Весьма удобно для блокировки кучи клонов StackOverflow
Интересно каким образом он обещает это сделать, если на уровне API pypi и аналогичные ему репозитории не умеют отдавать метаданные пакета без его скачивания?
Только в этом году, после переключения в pip на новый резолвер, оказавшийся очень медленным поначалу, разработчики всерьез взялись за исправление этой проблемы:
В итоге появился план вытаскивать из загружаемых .whl файлов список зависимостей и хранить его в отдельном файле, чтобы улучшить резолвинг зависимостей:
И правки до сих пор не смержили. Плюс это повлияет только на новые версии пакетов, обсуждение способа парсинге зависимостей уже залитых пактов все ещё идёт.
А без них, что pip, что poetry находятся в одинаковой ситуации - чтобы скачать зависимости пакета, нужно сначала скачать пакет, распарсить его метаданные, потом скачать его зависимости, зависимости его зависимостей и т.п.
Более того, проблема решаема только для .whl, потому что он собирается для определенной версии Python и ОС. А вот если выгружать в pypi исходники пакета в .tar.gz, метаданные из него вынуть не выйдет, потому что зависимости могут быть указаны в setup.py, т.е. определяться динамически в момент запуска сборки.
Что такого революционного предлагает poetry, кроме requirements.lock файла? Так это файл ему точно так же придется подготавливать, скачивая пакеты из pypi
Если сначала установить зависимости для одного окружения, а потом поверх установить зависимости для другого, poetry сначала удалит все пакеты первого окружения, и затем накатит второе. Как я понял, это было сделано для упрощения решения проблем с конфликтами версий установленных пакетов, поскольку так не нужно учитывать наличие уже установленных, но несовместимых друг с другом версий пакетов.
Но при этом он удаляет все пакеты старого окружения, в т.ч. и транзитивные зависимости. И если такой зависимостью случайно окажется virtualenv, он его удалит, и затем перестанет работать, т.к. сам от него зависит.
Да и если говорить о других зависимостях, сейчас это работает странно - poetry может считать, что зависимость установлена, хотя сам же ее и удалил при очистке окружения, и в итоге установка падает на пустом месте с кучей ошибок
При необходимости используйте в контейнерах виртуальные окружения Python
С одной стороны да, размер образа будет меньше. С другой, внутри контейнера, который и так даёт изоляцию окружения от хоста, зачем-то создаётся виртуальное окружение, которое изолирует зависимости от системного Python.
Плюс, нужно будет собирать stage на одном и том же базовом образе, поскольку по-умолчанию внутри venv пути к интерпретатору python на самом деле являются симлинками на системный python, а в разных дистрибутивах он может быть расположен по разным путям (где-то /usr/bin, где-то /usr/local/bin). А если использовать опцию --copy, то размер образа увеличивается, поскольку в venv создаётся копия файлов интерпретатора.
Плюс новички, увидев что внутри контейнера создаётся venv, могут по незнанию написать в своем Dockerfile что-нибудь вроде COPY venv/ /app/venv/. В таком варианте уже не приходится говорить ни о какой воспроизводимости сборки, как и о ее независимость от хоста, на котором она выполняется.
Больше года пользуюсь https://smartyoutubetv.github.io/ru/
Отлично работает на смарт ТВ (в отличие от Vanced). На мобиле пользоваться неудобно, но у него открытые исходники, так что можно доработать.
Понял, я почему-то после Python думал, что пока явно не добавить Promise в event_loop, он выполняться не будет
А где тут параллельность?
В комментариях к той статье уже спрашивали, но повторюсь.
Есть ли примеры крупных проектов, реализованных на $mol? Ссылки на компании, которые попробовали его использовать для разработки новых приложений? Сравнение скорости разработки чего-то сложнее Hello world? Отзывы новичков о сложности вкатывания в новую технологию?
Если $mol такая прорывная технология, то что-то не видно, чтобы за нее бизнес проголосовал рублем. А у разработчиков она определенно не в почете, судя по комментариям к каждой статье про этот фреймворк.
Потеряли ссылку на сам бенчмарк из оригинальной статьи: https://h2oai.github.io/db-benchmark/. Там хоть объясняется, что и как бенчмаркали.
Ну и в целом сравнение, где у всех остальных реализаций поголовно "out of memory", выглядит очень странно. Стоило бы сравнить на меньших объемах датасетов, чтобы хоть какие-то цифры были. Ну и "not implemented" у Spark выглядит смешно, уж groupBy и join там конечно есть.
Используйте rules для исключения ненужных шагов в master ветке
А теперь смотрим на то, где расположена клиника - Москва. Тут сейчас однушки стоят 10млн+, про трёшки я вообще молчу.
Пожалуйста: https://gist.github.com/dolfinus/907be2879604a0c2797372c039f4d907
Я пользуюсь вот этим скриптом для TamperMonkey, но он лишь позволяет скрыть определенные сайты из выдачи. Весьма удобно для блокировки кучи клонов StackOverflow
Я для этого пользуюсь вот этим скриптом для TamperMonkey. Ещё выше в одном из комментариев советуют uBlacklist.
Расскажите про это астматикам. Возможность задохнуться из-за реакции собственного иммунитета на какую-нибудь пыльцу страшнее гормонов.
Начиная с 3.4 asyncio является частью стандартной библиотеки Python.
Полагаю, тут подразумевалось что-то другое, потому как сейчас в этом нет никакого смысла.
Интересно каким образом он обещает это сделать, если на уровне API pypi и аналогичные ему репозитории не умеют отдавать метаданные пакета без его скачивания?
Только в этом году, после переключения в pip на новый резолвер, оказавшийся очень медленным поначалу, разработчики всерьез взялись за исправление этой проблемы:
https://github.com/pypa/warehouse/issues/8254
В итоге появился план вытаскивать из загружаемых .whl файлов список зависимостей и хранить его в отдельном файле, чтобы улучшить резолвинг зависимостей:
https://github.com/pypa/warehouse/pull/9972
И правки до сих пор не смержили. Плюс это повлияет только на новые версии пакетов, обсуждение способа парсинге зависимостей уже залитых пактов все ещё идёт.
А без них, что pip, что poetry находятся в одинаковой ситуации - чтобы скачать зависимости пакета, нужно сначала скачать пакет, распарсить его метаданные, потом скачать его зависимости, зависимости его зависимостей и т.п.
Более того, проблема решаема только для .whl, потому что он собирается для определенной версии Python и ОС. А вот если выгружать в pypi исходники пакета в .tar.gz, метаданные из него вынуть не выйдет, потому что зависимости могут быть указаны в setup.py, т.е. определяться динамически в момент запуска сборки.
Что такого революционного предлагает poetry, кроме requirements.lock файла? Так это файл ему точно так же придется подготавливать, скачивая пакеты из pypi
Недавно наткнулся на вот такой баг:
https://github.com/python-poetry/poetry/issues/3139
Если сначала установить зависимости для одного окружения, а потом поверх установить зависимости для другого, poetry сначала удалит все пакеты первого окружения, и затем накатит второе. Как я понял, это было сделано для упрощения решения проблем с конфликтами версий установленных пакетов, поскольку так не нужно учитывать наличие уже установленных, но несовместимых друг с другом версий пакетов.
Но при этом он удаляет все пакеты старого окружения, в т.ч. и транзитивные зависимости. И если такой зависимостью случайно окажется virtualenv, он его удалит, и затем перестанет работать, т.к. сам от него зависит.
Да и если говорить о других зависимостях, сейчас это работает странно - poetry может считать, что зависимость установлена, хотя сам же ее и удалил при очистке окружения, и в итоге установка падает на пустом месте с кучей ошибок
И в итоге сборка будет не воспроизводимой, потому что файл создавали на каком-то конкретном хосте, а не в явно заданном окружении в Dockerfile
В комментарии выше написано amd64
Но это ведь самая распространенная архитектура на текущий момент. И на dockerhub образ под нее есть с момента релиза:
Для erlang ведь давно собираются образы с arm64v8 архитектурой
Спасибо за статью, много полезных рекомендаций.
Однако с одним утверждением я не согласен:
С одной стороны да, размер образа будет меньше. С другой, внутри контейнера, который и так даёт изоляцию окружения от хоста, зачем-то создаётся виртуальное окружение, которое изолирует зависимости от системного Python.
Плюс, нужно будет собирать stage на одном и том же базовом образе, поскольку по-умолчанию внутри venv пути к интерпретатору python на самом деле являются симлинками на системный python, а в разных дистрибутивах он может быть расположен по разным путям (где-то /usr/bin, где-то /usr/local/bin). А если использовать опцию
--copy, то размер образа увеличивается, поскольку в venv создаётся копия файлов интерпретатора.Плюс новички, увидев что внутри контейнера создаётся venv, могут по незнанию написать в своем Dockerfile что-нибудь вроде
COPY venv/ /app/venv/. В таком варианте уже не приходится говорить ни о какой воспроизводимости сборки, как и о ее независимость от хоста, на котором она выполняется.Так что этот подход я бы не стал рекомендовать.