Ну что за элитизм?

это не элитизм вовсе

я про то, что у них в npm зависимости, в которых отдельная либа для реализации функции map, например

которая пишется руками за секунды

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

да и вообще, то, установится ли пакет npm’ом, зависит от фазы луны и сочетания звезд

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

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

Все там нормально, болячки и проблемы есть но решаются.

Вокруг js большая и живая экосистема

невозможно решить 1024+ зависимостей в среднем на проект

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

не знаю, я очень скептически отношусь к будущему js

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

и то не факт, что это поможет

потому что ни стабильных API, ни умения писать вещи руками от этого у народа не появится

Все там нормально, болячки и проблемы есть но решаются.

свежо предание

проблемы плохого дизайна ЯП, как показывает история, не решаются с сохранением обратной совместимости

короче, приходишь к мысли, что это не Python way, что нафига так жить если проще уже на ноде писать

Golang жи:)

aiohttp - штука активно развивающаяся и они там много чего ломают, это да

Ну, развитие не мешает делать многое аккуратно. Хотя там нечего ломать, @stepanz не апи и был. Что в aiohttp, что в asyncio. Я первый раз когда-то увидел, у меня чуть глазками кровь не пошла. По четыре слова в именах методов? Офонарели совсем.

Ну, развитие не мешает делать многое аккуратно. Хотя там нечего ломать, @stepanz не апи и был. Что в aiohttp, что в asyncio. Я первый раз когда-то увидел, у меня чуть глазками кровь не пошла. По четыре слова в именах методов? Офонарели совсем.

не вижу проблемы в четырех словах, если код читабельнее от этого

слишком много явного это уже шум, хотел бы шума писал бы на го

Только там тебе не дают в таких вещах ошибаться обычно.

ну лан, я не в брасыаю, я ж из опыта работы и с тем и с другим. просто мой совет сильно не обольщаться по поводу asyncio, не все там радужно и просто

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

а я грущу, что в javascript нет вокруг генераторов/итераторов экосистемы и нет list comprehensions вообще (

Есть мапы, есть object/list augmentation

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

Он уже. ES6 весьма приятнее того же руби или пхп.

Он уже. ES6 весьма приятнее того же руби или пхп.

так-то да, но говноинфраструктуру это не исправит

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

Это происходит с завидной регулярностью там. Вот yarl

yarn

Это происходит с завидной регулярностью там. Вот yarl

в питоне есть pip уже сотню лет, а distribute и setuptools уже давно слили в один пакет

yarn хорош, хотя там были проблемы

почему такого же нет в js?

Лол

не вижу проблемы в четырех словах, если код читабельнее от этого

Он визуально выглядит говном вот прямо сразу как такое появляется

Как каша из setup.py может быть лучше package.json?

Он визуально выглядит говном вот прямо сразу как такое появляется

субъективно весьма

yarn

Угу

Как каша из setup.py может быть лучше package.json?

ээ, легко? там нет каши, там один метод

в питоне есть pip уже сотню лет, а distribute и setuptools уже давно слили в один пакет

И пип не решает многого и потому есть pipfile, но идет с трудом. Скорость развития не сравнима с yarn и webpack

почему такого же нет в js?

Боже упаси их от pip

Как каша из setup.py может быть лучше package.json?

Те же яйца, вид с боку

И пип не решает многого и потому есть pipfile, но идет с трудом. Скорость развития не сравнима с yarn и webpack

ну да, наверное, поэтому он прыгнул с версии 1.5 до версии 10.0 за несколько лет

Боже упаси их от pip

но pip лучше того, что там сейчас

ээ, легко? там нет каши, там один метод

Это пока пакетов не 30 в зависимостях и они не тянут еще четыре слоя за собой

Это пока пакетов не 30 в зависимостях и они не тянут еще четыре слоя за собой

а в чем проблема?

Всем привет! Может кто знает ответ? http://ru.stackoverflow.com/questions/631587/

Несколько лет по меркам js -это вечность;)

В чем угодно. В зависимости двух пакетов от разных версий третьего.

В конфликте новой версии пакета, от которого ты зависишь, с новой версией зависимости его зависимости.

В чем угодно. В зависимости двух пакетов от разных версий третьего.

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

точнее как, решения два

либо ставить одну из версий, либо падать

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

Её нет в npm. Её нет в go. Её нет в c/c++. Невозможно:)

Её нет в npm. Её нет в go. Её нет в c/c++. Невозможно:)

что значит “ее нет”? она есть

ее не может не быть

вопрос только в том, как она решается

ее не может не быть

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

И только в Питоне с глобальным реестром импортированных модулей в рантайме мы получили pip.

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

интересно, каким образом это возможно в C/C++, где все зависимости объединяются в одну портянку?

В Java и Ruby - как в Питоне. В go уже сделали локальные зависимости пакета.

интересно, каким образом это возможно в C/C++, где все зависимости объединяются в одну портянку?

Ну, там можно хитро собрать, статично включая каждой либе её зависимости.

ну, в питоне ты можешь на несколько виртуаленвов сетап размазывать и перекидывать между ними данные pickle, теоретически...

будет примерно то же самое

это автоматизировать даже можно, при желании

говно, конечно, получится, но все же

говно, конечно, получится, но все же

Это ахтунг и велосипед масштабов космолета, чтобы получить npm:)

Это ахтунг и велосипед масштабов космолета, чтобы получить npm:)

ой, да ладно, а то в npm это решено

когда я пишу в require какой-то пакет - какая мне версия подсосется?

ERROR: S client not available

ну, в питоне ты можешь на несколько виртуаленвов сетап размазывать и перекидывать между ними данные pickle, теоретически...

С этого места я просто пилю отдельный сервис с отдельной функциональностью, да типа отдельный сетап;)

когда я пишу в require какой-то пакет - какая мне версия подсосется?

Из твоего package.json

А если ты пишешь require и не написал в package.json, то прости.

А если ты пишешь require и не написал в package.json, то прости.

ну так это хрень же

мне надо что, все стопицот зависимостей туда писать?

А если ты пишешь require и не написал в package.json, то прости.

Ну и require фуфуфу же. import уже;)

мне надо что, все стопицот зависимостей туда писать?

Все прямые. А в Питоне ты не так делаешь?

Или поставил flask и надеешься, что с версией Mako не будет проблем, если её импортировать?

делаю, но, например, я знаю, что pandas включает в себя dateutil и six, поэтому их необязательно напрямую указывать

иначе может как раз начаться говно с версиями

делаю, но, например, я знаю, что pandas включает в себя dateutil и six, поэтому их необязательно напрямую указывать

О Б Я З А Т Е Л Ь Н О

О Б Я З А Т Е Л Ь Н О

с гвоздями прибитой версией? нет

только с диапазоном минимум

иначе может как раз начаться говно с версиями

Лучше говно с версиями у тебя, чем говно с проектом в проде.

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

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

все просто работает

только с диапазоном минимум

С гвоздями прибитой явно в r11.txt проблем не будет.

С гвоздями прибитой явно в r11.txt проблем не будет.

Только и с версиями flask и mako, только так.

С гвоздями прибитой явно в r11.txt проблем не будет.

это тогда будет dependency hell

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

о, а я, кстати, вспомнил готовое решение

можно вместо прямого импорта использовать поиск через pkg_resources

конкретной версии

Я устал это писать. pip freeze -r r11.in > r11.txt

и тогда можно будет без ада

интересно, надо попробовать

и тогда можно будет без ада

Оно не даст иметь две разных в одном рантайме. Просто упадёт.

Оно не даст иметь две разных в одном рантайме. Просто упадёт.

даст, если их под разными неймспейсами импортировать

ты можешь, скажем, в pandas заимпортить dateutil, обозвав его pandas_dateutil

ты можешь, скажем, в pandas заимпортить dateutil, обозвав его pandas_dateutil

Попробуй. Есть подозрение, что оно в sys.modules оригинальное имя кладет.

А как их установить рядом, чтобы оба нашлись?