Вы используете асинхронный aiogram, но синхронные requests и psycopg2. На ваших нагрузках это скорее всего не заметно, но в общем случае так делать не стоит, потому что вы получаете по сути синхронное приложение выдающее очень низкий rps и блокирующее всё общение с пользователями на время долгого запроса в http или базу. Для асинхронной работы есть aiohttp и aiopg/asyncpg.
Практическая жизнеспособность позиции автора оценивается очень просто - появлением форка. Пока нет форка, описанная политика полностью соответствует заданной цели - отфильтровать паразитов, причём не в ущерб открытой разработке продукта. В этом смысле уверен что похожей политики в неявном виде придерживается большинство открытых проектов - откровенно мусорные или наглые issue закрываются без лишних комментариев или просто игнорируются.
В целом же позиция автора не соответствует духу F/OSS движения (в моём понимании, по крайней мере), который, грубо говоря, и заключается в решении чужих задач за свои средства ради общего блага, и как минимум подразумевает предоставление сообществу средств решать проблемы самостоятельно (тот же форум). Здесь же налицо конфликт интересов с коммерческой разработкой (что, кстати, подтверждает мою позицию о невозможности смешивания коммерции и F/OSS) и по итогу продукт который несёт пользователям риски характерные для проприетарного ПО.
Но в общем да, всё равно это выглядит как справедливый противовес растущему числу потребителей, пришедших к F/OSS и считающих что он *для них лично*.
>Для неизменяемых типов переменные с одинаковым значением будут иметь одинаковый адрес памяти
Не будут, хотя это и возможно в частных случаях.
>Изменяемые аргументы передаются по ссылкам, а неизменяемые – по значениям
Всегда по ссылкам. Ваши примеры не эквивалентны, поскольку some_arg.append() - изменение, `some_arg = some_arg + 1` - создание нового объекта и сохранение ссылки на него в переменную.
>При присваивании b значения a, переменная b всегда будет ссылаться на тот же адрес памяти, что и a.
Это всё что должно быть написано в этом пункте. От типа переменной a не зависит ничего. Кажется, вы не совсем разобрались в разнице между изменением объекта и созданием нового.
>Спор касался способа хранения в памяти списка (list).
Если все декомпозируют свою задачу, описанной проблемы вообще не возникает. Здесь же решается задача когда нужно влить 2 недели разработки кода, который в этом время значительно менялся другими людьми.
Ну как же, именно работать в отрыве от команды и предлагается, об этом явно написано:
> включить для себя, выключить для всех остальных > итеративно делать новую реализацию
и в конце
> выключить и удалить старую реализацию
Но старая реализация же активно разрабатывается, иначе откуда взяться конфликтам слияния, которых хотели избежать? Вот вся эта разработка и будет в последнем пункте разом silently потеряна. Так не обязательно было для этого новую технику придумывать, можно было просто влить feature ветку с -s recursive -X theirs.
Иначе другие разработчики должны были вносить изменения в обе ветки, но это точно не про "выключить для всех остальных", а скорее про "заставить остальных разработчиков коммитить все изменения в две ветки [кода] сразу (при том что одна из них недописана) и обе этих ветки тестировать". Во было бы интересно почитать как это было организовано, как контролировалось, как масштабировалось, и оправдало ли себя.
Делаете pull request, он висит несколько дней, после этого вы получаете approve и ... 15 конфликтов
Но ведь это замечательно, теперь вы знаете что код ещё кто-то менял и как именно, и имеете возможность обдуманно слить изменения. Предложенная техника в этом аспекте - способ проигнорировать и выкинуть чужую работу, которой может быть и критичное изменение бизнес-логики. А так-то слишком много слов для "написать независимую реализацию куска кода и заменить ей существующий".
Столько воды про очевидные, в общем, вещи, а главный вопрос - чем отличаются article и section, на который никто внятно ответить не может - опять не затронут.
Это не имеет значения потому что есть catch(...), а вообще код который кидает что-то не унаследованное от std::exception можно смело приравнивать к ill-formed.
Помню sonique, про него ещё ходили слухи что в нем качество звучания лучше из-за собственного декодера. Но ни winamp ни sonique удобными с точки зрения gui никогда не были, потому что для плеера и gui-то и не нужен - он должен играть в фоне, управляться хоткеями и не занимать место на экране. Из gui нужен только редактор плейлиста. Есть правда кейс 'party mode' когда нужен именно плеер на весь экран с визуализациями и свистелками.
Думаю, код, выбрасывающий исключение всякий раз, когда произойдет что-то неожиданное, сложен для понимания, и его тяжелее поддерживать.
Это утверждение требует доказательства, без которого вся статья не имеет смысла. Мой опыт показывает обратное - только при использовании исключений код будет прозрачным, очевидным и сконцентрированным на том что мы делаем, а не на том что может пойти не так. Код обработки ошибок будет обособлен в ограниченном числе мест на верхнем уровне где мы можем сделать что-то осмысленное, а где-то вообще не нужен - консольное приложение пусть просто упадёт (в Python будет готовый трейс, в C++, ок, придётся обернуть main в try чтобы распечатать what()). В веб бэкенде исключение перехватится на уровне обработки запроса и клиенту вернётся 503. В GUI приложении я бы обернул,например, только целиком код open/save чтобы сказать "не шмогла" и продолжить работу.
Все же подходы с возвратом значений заставляют думать об обработке ошибок в каждой строке, на каждом шаге. Даже если это сделано как в rust - односимвольным оператором, мне все равно надо думать, возвращает ли эта функция голое значение или Result, хочу ли я ? или !, и что будет если сторонний код который я вызываю вызовет panic? Если функция не возвращала ошибку, но начала возвращать, мне придётся менять все её вызовы (в полюсах есть похожая проблема с noexcept, но он про оптимизацию и его можно, а в публичных интерфейсах, пожалуй, и нужно не использовать.
Но да, в редких случаях когда нужно контролировать каждый шаг алгоритма Result с монадическим интерфейсом удобен. В прочем, в языке в котором есть исключения можно без особых проблем обернуться одно в другое (может быть с точностью до производительности).
Это, возможно, только верхушка проблем с JIT. С год назад я чинил в 13.0 устойчивое падение бэкенда в llvmjit на FreeBSD. В двух словах, там оказалось что LLVM не умеет инлайнить функции с обращениями к thread local storage, а под FreeBSD в TLS хранятся параметры локали, которые используются из функций типа isspace(). isspace(), в свою очередь, используется много где в коде PostgreSQL, в частности при конвертации типов (чтобы пропустить не значащие пробелы), например при конвертации текста/json в bool (boolin()), где оно, собственно и падало. В Linux, видимо, isspace() устроена по другому, поэтому там это так сильно не стреляло.
Так вот, оказалось что testsuite постгреса не прогонялся с JIT вообще (он даже не собирался с поддержкой JIT; ЕМНИП там код должен был собираться два раза - по классике для обычных вызовов и в объектный код LLVM для JIT). Не знаю, может быть с тех пор это починили, но непокрытую тестами фичу я бы на месте авторов постгреса не стал выкатывать.
В целом я не понимаю людей которые обновляют major version на проде через две недели после выхода и на след. день после релиза облачного провайдера. Другое поколение. Можно обозвать меня бумером - так оно и есть.
А что вы предлагаете, ждать и надеяться что кто-то наступит на тот же баг что случится у вас, его зарепортят и починят? Сколько именно нужно ждать? Придерживаться ли ритуалов вроде "никогда не ставить x.0"? Какие это даст гарантии? Может вообще не обновляться?
И да, если погонять нагрузку в staging подольше, то вероятность обнаружения ошибки увеличивается.
Вот же правильный ответ, только на stg можно гонять следующий релиз задолго до собственно релиза. А если на stg под рабочей нагрузкой идеально работает хоть альфа, что мешает выкатить хоть альфу в прод если от этого будет профит? Тем более что можно выкатить на 10% кластера и мгновенно откатить?
В прошлом веке не было инструментов позволяющих одной кнопкой сделать копию прода, выкатить туда любую версию любого сервиса, и убедиться что всё это ожидаемо работает, а в случае проблем безболезненно откатиться. Поэтому ждали "стабилизации" и всё равно тряслись при каждом мажорном обновлении. Сейчас это бессмысленно - при современном подходе к разработке и деплою можно хоть из git всё собирать с минимальным риском.
А последнее время райф вообще оставляет ощущение поделки либо помирающей конторы.
Например, чат в online.raiffeisen.ru через который делаются всякие нужные вещи уже с год не работает в firefox, потому что текст сжимается до колонки в 10 пикселей.
Сейчас воспользовался другим чатом chat.raiffeisen.ru, чтобы туда войти достаточно ввести имя и телефон, при этому СМС подтверждения не требуется. Захожу, прошу открыть счёт, ответ "хорошо, откроем счёт, скинем реквизиты на почту, ваша почта xxx@yyy актуальна?". То есть первому неавторизованному встречному сходу как минимум сливают мою личную почту. Скорее всего наинженерить и что-то посерьёзнее.
Потом, они подозрительным образом позакрывали все отделения и банкоматы в округе (районы Лосиноостровский, Южное Медведково Москвы), а те что остались работают через раз. По карте хорошо видно что на большей части Москвы банкоматов в пешей доступности не осталось.
Уже пару лет тестирую mastodon, и пока это вызывает только лютую печаль.
Нет никакой возможности фильтровать полезный контент. Из трёх упомянутых лент:
Глобальная бесполезна, потому что это сплошной поток (и уже довольно значительного объёма) нерелевантного мусора. Ото всех подряд, обо всём подряд (хотя в основном ни о чём, т.е. shitposts), на всех подряд языках (фильтр по языку есть, но не похоже чтобы он работал).
Локальная бесполезна, потому что отсекает большую часть постов по синтетическому признаку (принадлежности к инстансу). Хотя она и может иметь более высокую среднюю релевантность если вы выберете правильный тематический инстанс. Но, во-первых, обычно на тематических инстансах явно не запрещены другие темы и всё равно на инстансе про СПО получаем фотки еды и домашних животных и обсуждение ковида, во-вторых, что делать если мне интересно несколько тем, не плодить же аккаунты?
Подписки на пользователей бесполезны потому что даже если подписаться на кого-нибудь из-за качественного интересного поста, следующим постом обязательно пойдёт еда, политика, ковид, superbowl и прочая ерунда.
Можно использовать разве что средства фильтрации на хэштегам, которые прикручены сбоку, не во всех клиентах, везде реализованы по-разному, везде неудобно и не синхронизируются. Скажем, в web интерфейсе мастодона это возможно только в "advanced" режиме, который представляет собой кошмарное с точки зрения юзабилити решение из нескольких колонок. В обычном режиме с единой лентой фильтровать по хэштегам нельзя. Даже с фильтрацией по хэштегам в ленту будет попадать мусор, поэтому сверху это посыпается mute сотен аккаунтов и целых инстансов и ещё (по всей видимости родными мастодоновскими) исключающими фильтрами по кейвордам, которые тоже не очень понятно работают ли как ожидается.
К платформе тоже есть вопросы. Пока впечатление такое что цензура там куда реальнее чем в централизованных сетях, при этом злее и неадекватнее. Кто-то позволил себе не поддержать BLM/SJW, сразу начинаются призывы (а к слову, неадекватных SJW которых забанили в других сетях в fediverse пруд пруди) забанить (defederate) весь его инстанс. И админам приходится дефедерироваться, иначе начинают дефедерироваться уже с ними.
В общем, для меня взаимодействие с сетью сводится к когда прям совсем нечего делать полистать жёсткую выжимку по хэштегам и ничего интересного там не найти. Ну или написать что-то вникуда, может пара человек увидит. Интересно было бы узнать про отличный от моего опыт. Ещё всегда было интересно, сильно ли это отличется от twitter, или там такая же помойка.
Мне кажется что чистый разум преследует две цели — творение и исследование, и при отказе от любой из них получается бессмысленный деградант. Тут конечно можно поспорить что совокупность творящих разумов является неиссякаемым источником неисследованного друг для друга, но всё-таки как ни крути она будет ограничена возможностями и самих разумов, и среды их существования. Поэтому реальность должна быть притягательна как сама по себе, так и потенциальной возможностью существования надреальностей.
По этой же причине оставаться в нашей солнечной системе такой цивилизации не имеет смысла. Наверняка есть какой-то баланс вычислительной мощности и потребляемой энергии по достижении которого наращивание "железа" перестаёт быть целесообразным, доступ к большому объёму материи становится не нужен, и остаётся затариться дейтерием или там антивеществом и полететь туда где интереснее. А с собой взять достаточно данных о родном мире чтобы не понадобилось возвращаться.
Это очень хорошо, сказал он, потому что теперь можно использовать BigQuery на индексе репозитория!
Это же очень давно можно, и это большая проблема, потому что полные метаданные о пакетах в PyPI можно получить только через проприетарное гугловское API, требующее ещё и наличия Google аккаунта. Для Repology, например, мне пришлось написать сервис который собирает частичные метаданные из нескольких разнородных, полурабочих и частично deprecated API, вместо того чтобы просто скачать json, как это делается для других поддерживаемых коллекций модулей включая RubyGems, crates.io, CPAN, CRAN, MELPA, Hackage, LuaRocks и т.д.
Очень неприятно что постулируется первичность работы и вторичность "pet-проекта". Как насчёт того что, наоборот, основной деятельностью талантливого разработчика является развитие собственных проектов, а работа — всего лишь средство поддержки этой деятельности?
Кстати, чтобы проще было попасть в пакетные репозитории неплохо было бы ответственнее относиться к релизам. А у вас в cmake версия 2.2.0, а в тэгах какое-то alpha-17sep20.
Вы используете асинхронный aiogram, но синхронные requests и psycopg2. На ваших нагрузках это скорее всего не заметно, но в общем случае так делать не стоит, потому что вы получаете по сути синхронное приложение выдающее очень низкий rps и блокирующее всё общение с пользователями на время долгого запроса в http или базу. Для асинхронной работы есть aiohttp и aiopg/asyncpg.
Практическая жизнеспособность позиции автора оценивается очень просто - появлением форка. Пока нет форка, описанная политика полностью соответствует заданной цели - отфильтровать паразитов, причём не в ущерб открытой разработке продукта. В этом смысле уверен что похожей политики в неявном виде придерживается большинство открытых проектов - откровенно мусорные или наглые issue закрываются без лишних комментариев или просто игнорируются.
В целом же позиция автора не соответствует духу F/OSS движения (в моём понимании, по крайней мере), который, грубо говоря, и заключается в решении чужих задач за свои средства ради общего блага, и как минимум подразумевает предоставление сообществу средств решать проблемы самостоятельно (тот же форум). Здесь же налицо конфликт интересов с коммерческой разработкой (что, кстати, подтверждает мою позицию о невозможности смешивания коммерции и F/OSS) и по итогу продукт который несёт пользователям риски характерные для проприетарного ПО.
Но в общем да, всё равно это выглядит как справедливый противовес растущему числу потребителей, пришедших к F/OSS и считающих что он *для них лично*.
>Для неизменяемых типов переменные с одинаковым значением будут иметь одинаковый адрес памяти
Не будут, хотя это и возможно в частных случаях.
>Изменяемые аргументы передаются по ссылкам, а неизменяемые – по значениям
Всегда по ссылкам. Ваши примеры не эквивалентны, поскольку
some_arg.append()- изменение, `some_arg = some_arg + 1` - создание нового объекта и сохранение ссылки на него в переменную.>Аннотации типов выполняются не в runtime.
Так всё-таки, когда?
>При присваивании
bзначенияa, переменнаяbвсегда будет ссылаться на тот же адрес памяти, что иa.Это всё что должно быть написано в этом пункте. От типа переменной
aне зависит ничего. Кажется, вы не совсем разобрались в разнице между изменением объекта и созданием нового.>Спор касался способа хранения в памяти списка (list).
Странно спорить об однозначно определённый вещах. Не так явно как могло быть, но всё же задокументированных https://docs.python.org/3.9/glossary.html#term-list
Если все декомпозируют свою задачу, описанной проблемы вообще не возникает. Здесь же решается задача когда нужно влить 2 недели разработки кода, который в этом время значительно менялся другими людьми.
Ну как же, именно работать в отрыве от команды и предлагается, об этом явно написано:
> включить для себя, выключить для всех остальных
> итеративно делать новую реализацию
и в конце
> выключить и удалить старую реализацию
Но старая реализация же активно разрабатывается, иначе откуда взяться конфликтам слияния, которых хотели избежать? Вот вся эта разработка и будет в последнем пункте разом silently потеряна. Так не обязательно было для этого новую технику придумывать, можно было просто влить feature ветку с
-s recursive -X theirs.Иначе другие разработчики должны были вносить изменения в обе ветки, но это точно не про "выключить для всех остальных", а скорее про "заставить остальных разработчиков коммитить все изменения в две ветки [кода] сразу (при том что одна из них недописана) и обе этих ветки тестировать". Во было бы интересно почитать как это было организовано, как контролировалось, как масштабировалось, и оправдало ли себя.
Но ведь это замечательно, теперь вы знаете что код ещё кто-то менял и как именно, и имеете возможность обдуманно слить изменения. Предложенная техника в этом аспекте - способ проигнорировать и выкинуть чужую работу, которой может быть и критичное изменение бизнес-логики. А так-то слишком много слов для "написать независимую реализацию куска кода и заменить ей существующий".
Столько воды про очевидные, в общем, вещи, а главный вопрос - чем отличаются article и section, на который никто внятно ответить не может - опять не затронут.
Это не имеет значения потому что есть
catch(...), а вообще код который кидает что-то не унаследованное отstd::exceptionможно смело приравнивать к ill-formed.Помню sonique, про него ещё ходили слухи что в нем качество звучания лучше из-за собственного декодера. Но ни winamp ни sonique удобными с точки зрения gui никогда не были, потому что для плеера и gui-то и не нужен - он должен играть в фоне, управляться хоткеями и не занимать место на экране. Из gui нужен только редактор плейлиста. Есть правда кейс 'party mode' когда нужен именно плеер на весь экран с визуализациями и свистелками.
Для Linux их было/есть полно - xmms(2), audacious, qmmp, ещё что-то. Ими не пользуются потому что есть гораздо более удобные mpd и moc.
Нет, не приводит, потому что перехватывается std::exception.
Это утверждение требует доказательства, без которого вся статья не имеет смысла. Мой опыт показывает обратное - только при использовании исключений код будет прозрачным, очевидным и сконцентрированным на том что мы делаем, а не на том что может пойти не так. Код обработки ошибок будет обособлен в ограниченном числе мест на верхнем уровне где мы можем сделать что-то осмысленное, а где-то вообще не нужен - консольное приложение пусть просто упадёт (в Python будет готовый трейс, в C++, ок, придётся обернуть main в try чтобы распечатать what()). В веб бэкенде исключение перехватится на уровне обработки запроса и клиенту вернётся 503. В GUI приложении я бы обернул,например, только целиком код open/save чтобы сказать "не шмогла" и продолжить работу.
Все же подходы с возвратом значений заставляют думать об обработке ошибок в каждой строке, на каждом шаге. Даже если это сделано как в rust - односимвольным оператором, мне все равно надо думать, возвращает ли эта функция голое значение или Result, хочу ли я ? или !, и что будет если сторонний код который я вызываю вызовет panic? Если функция не возвращала ошибку, но начала возвращать, мне придётся менять все её вызовы (в полюсах есть похожая проблема с noexcept, но он про оптимизацию и его можно, а в публичных интерфейсах, пожалуй, и нужно не использовать.
Но да, в редких случаях когда нужно контролировать каждый шаг алгоритма Result с монадическим интерфейсом удобен. В прочем, в языке в котором есть исключения можно без особых проблем обернуться одно в другое (может быть с точностью до производительности).
Это, возможно, только верхушка проблем с JIT. С год назад я чинил в 13.0 устойчивое падение бэкенда в llvmjit на FreeBSD. В двух словах, там оказалось что LLVM не умеет инлайнить функции с обращениями к thread local storage, а под FreeBSD в TLS хранятся параметры локали, которые используются из функций типа isspace(). isspace(), в свою очередь, используется много где в коде PostgreSQL, в частности при конвертации типов (чтобы пропустить не значащие пробелы), например при конвертации текста/json в bool (boolin()), где оно, собственно и падало. В Linux, видимо, isspace() устроена по другому, поэтому там это так сильно не стреляло.
Так вот, оказалось что testsuite постгреса не прогонялся с JIT вообще (он даже не собирался с поддержкой JIT; ЕМНИП там код должен был собираться два раза - по классике для обычных вызовов и в объектный код LLVM для JIT). Не знаю, может быть с тех пор это починили, но непокрытую тестами фичу я бы на месте авторов постгреса не стал выкатывать.
А что вы предлагаете, ждать и надеяться что кто-то наступит на тот же баг что случится у вас, его зарепортят и починят? Сколько именно нужно ждать? Придерживаться ли ритуалов вроде "никогда не ставить x.0"? Какие это даст гарантии? Может вообще не обновляться?
Вот же правильный ответ, только на stg можно гонять следующий релиз задолго до собственно релиза. А если на stg под рабочей нагрузкой идеально работает хоть альфа, что мешает выкатить хоть альфу в прод если от этого будет профит? Тем более что можно выкатить на 10% кластера и мгновенно откатить?
В прошлом веке не было инструментов позволяющих одной кнопкой сделать копию прода, выкатить туда любую версию любого сервиса, и убедиться что всё это ожидаемо работает, а в случае проблем безболезненно откатиться. Поэтому ждали "стабилизации" и всё равно тряслись при каждом мажорном обновлении. Сейчас это бессмысленно - при современном подходе к разработке и деплою можно хоть из git всё собирать с минимальным риском.
А последнее время райф вообще оставляет ощущение поделки либо помирающей конторы.
Например, чат в online.raiffeisen.ru через который делаются всякие нужные вещи уже с год не работает в firefox, потому что текст сжимается до колонки в 10 пикселей.
Сейчас воспользовался другим чатом chat.raiffeisen.ru, чтобы туда войти достаточно ввести имя и телефон, при этому СМС подтверждения не требуется. Захожу, прошу открыть счёт, ответ "хорошо, откроем счёт, скинем реквизиты на почту, ваша почта xxx@yyy актуальна?". То есть первому неавторизованному встречному сходу как минимум сливают мою личную почту. Скорее всего наинженерить и что-то посерьёзнее.
Потом, они подозрительным образом позакрывали все отделения и банкоматы в округе (районы Лосиноостровский, Южное Медведково Москвы), а те что остались работают через раз. По карте хорошо видно что на большей части Москвы банкоматов в пешей доступности не осталось.
Уже пару лет тестирую mastodon, и пока это вызывает только лютую печаль.
Нет никакой возможности фильтровать полезный контент. Из трёх упомянутых лент:
Можно использовать разве что средства фильтрации на хэштегам, которые прикручены сбоку, не во всех клиентах, везде реализованы по-разному, везде неудобно и не синхронизируются. Скажем, в web интерфейсе мастодона это возможно только в "advanced" режиме, который представляет собой кошмарное с точки зрения юзабилити решение из нескольких колонок. В обычном режиме с единой лентой фильтровать по хэштегам нельзя. Даже с фильтрацией по хэштегам в ленту будет попадать мусор, поэтому сверху это посыпается mute сотен аккаунтов и целых инстансов и ещё (по всей видимости родными мастодоновскими) исключающими фильтрами по кейвордам, которые тоже не очень понятно работают ли как ожидается.
К платформе тоже есть вопросы. Пока впечатление такое что цензура там куда реальнее чем в централизованных сетях, при этом злее и неадекватнее. Кто-то позволил себе не поддержать BLM/SJW, сразу начинаются призывы (а к слову, неадекватных SJW которых забанили в других сетях в fediverse пруд пруди) забанить (defederate) весь его инстанс. И админам приходится дефедерироваться, иначе начинают дефедерироваться уже с ними.
В общем, для меня взаимодействие с сетью сводится к когда прям совсем нечего делать полистать жёсткую выжимку по хэштегам и ничего интересного там не найти. Ну или написать что-то вникуда, может пара человек увидит. Интересно было бы узнать про отличный от моего опыт. Ещё всегда было интересно, сильно ли это отличется от twitter, или там такая же помойка.
Мне кажется что чистый разум преследует две цели — творение и исследование, и при отказе от любой из них получается бессмысленный деградант. Тут конечно можно поспорить что совокупность творящих разумов является неиссякаемым источником неисследованного друг для друга, но всё-таки как ни крути она будет ограничена возможностями и самих разумов, и среды их существования. Поэтому реальность должна быть притягательна как сама по себе, так и потенциальной возможностью существования надреальностей.
По этой же причине оставаться в нашей солнечной системе такой цивилизации не имеет смысла. Наверняка есть какой-то баланс вычислительной мощности и потребляемой энергии по достижении которого наращивание "железа" перестаёт быть целесообразным, доступ к большому объёму материи становится не нужен, и остаётся затариться дейтерием или там антивеществом и полететь туда где интереснее. А с собой взять достаточно данных о родном мире чтобы не понадобилось возвращаться.
Это же очень давно можно, и это большая проблема, потому что полные метаданные о пакетах в PyPI можно получить только через проприетарное гугловское API, требующее ещё и наличия Google аккаунта. Для Repology, например, мне пришлось написать сервис который собирает частичные метаданные из нескольких разнородных, полурабочих и частично deprecated API, вместо того чтобы просто скачать json, как это делается для других поддерживаемых коллекций модулей включая RubyGems, crates.io, CPAN, CRAN, MELPA, Hackage, LuaRocks и т.д.
Очень неприятно что постулируется первичность работы и вторичность "pet-проекта". Как насчёт того что, наоборот, основной деятельностью талантливого разработчика является развитие собственных проектов, а работа — всего лишь средство поддержки этой деятельности?
Кстати, чтобы проще было попасть в пакетные репозитории неплохо было бы ответственнее относиться к релизам. А у вас в cmake версия
2.2.0, а в тэгах какое-тоalpha-17sep20.