Переписать Portage на Go, почему нет?

Они решают ту же проблему, но быстрее проще и универсальнее

Задачу да одну и ту же. А вот проблемы они решают несколько разные.

Нет, nix-лайк пакетные менеджеры решают другую проблему.

Если задача это поставить и обновлять пакеты no matter how, то можно с натяжкой согласиться.

Если задача это поставить и обновлять пакеты no matter how, то можно с натяжкой согласиться.

Если «no matter how» то ./configure && make && make install всяко решает.

Обновлять и следить удалять не поддерживается нормально. А так да.

у них вроде еще гдето остался 4.2.1

мой поинт был в том что неплохо было бы сравнить время сборки и/или время просчета дерева зависимостей для какого-то generic пакета который присутствует в обоих системах (например ncurses или readline). при этом средства сборки должны быть +- одинаковыми (gcc 4.2.1), а pm должны отличатся: у нас последний стабильный портаж vs последний стабильный pkg. если время сбори на одном и том же железе будет отличатся на более чем 5с-10с не в нашу пользу думаю этот факт долден говорить сам за себя..

kep, затея сдулась?

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

Если будут новости – рад буду слышать, подписался на тред.

Или работает медленно не по причине питона?

нет. по причине того, что портадж это куча кривых костылей, обмазанная питоном. смотри например блог ciaranm, разработчика paludis/cave и кривизну — он адекватно сравнивает PMS, спецификацию и в итоге приходит к выводу, что ебилды кривые по определению, а вот exheres в Exherbo более правильный путь, да и палудис тут более правильный, чем портадж.

вообще, выбор именно Go странный (хотя горутины, да).

можно было бы и на Nim переписать — тоже ведь в каком-то смысле питон, с async/await асинхронщиной и няшными AST макросами. в итоге ебилды через макросы, с тайпчекингом можно забубенить, ога.

nix и конкретно его развитие, guix на схеме как-то более разумно смотрится, несмотря на.

Кстати, это сначала удивило (цитата из http://git.savannah.gnu.org/cgit/guix.git/tree/README?id=v0.8.3)

GNU Guix is based on the Nix package manager. It implements the same package deployment paradigm, and in fact it reuses some of its code. Yet, different engineering decisions were made for Guix, as described below.

ебилды на схеме, в S-выражениях выглядят забавно. когда-нибудь надо будет написать «компилятор ебилдов» — из рецептов сборки gentoo в guix-рецепты. c юз-флагами, правда, непонятно что делать — идеологически.

Импорт из pypi, cpan и т.д. там есть, то есть импорт ебилдов тоже возможен, но или юзов не будет, или будут какие-нибудь надстройки над guix.