История изменений
Исправление vvn_black, (текущая версия) :
Нет, не переписывает.
У него есть критика, что кодовая база Portage в 135000 строк кода на Python используется только двумя утилитами - emerge и ebuild, и не используется другими инструментами.
Поэтому, он разрабатывает инструмент subpop, который за счёт Plugin-oriented programming позволит расширять funtoo-metatools плагинами и даст доступ сторонним приложениям и утилитам к возможностям funtoo-metatools.
Also, please note – my intent in mentioning Portage is not to pick on it, or those who have maintained it over the years whose efforts I appreciate, but rather to explain why I am so excited about building metatools and creating a framework that can be more successfully leveraged by the Open Source community. My long-held desire to continue to improve Portage has been restrained by the very structure of the source code that has evolved within it. Originally, Portage was a tool that solved problems. It created new paradigms. It has evolved into something that while still cool, also enforces a paradigm that is hard to change and adapt to new problems.
Due to our use of subpop, much of metatools functionality is extensible via plugins. Plugins can be used to enhance the core functionality of the tool in a modular ‘plug-n-play’ way, reducing code bloat. Subpop also encourages a simple, microservices-style archictecture within the code itself. All this is very good for a complex problem like the automation of updates of packages for the world’s source code.
Исходная версия vvn_black, :
Нет, не переписывает.
У него есть критика, что кодовая база Portage в 135000 строк кода на Python используется только двумя утилитами - emerge и ebuild, и не используется другими инструментами.
Поэтому, он разрабатывает инструмент subpop, который за счёт Plugin-oriented programming позволит расширять funtoo-metatools за счёт плагинов и даст доступ сторонним приложениям и утилитам к возможностям funtoo-metatools.
Also, please note – my intent in mentioning Portage is not to pick on it, or those who have maintained it over the years whose efforts I appreciate, but rather to explain why I am so excited about building metatools and creating a framework that can be more successfully leveraged by the Open Source community. My long-held desire to continue to improve Portage has been restrained by the very structure of the source code that has evolved within it. Originally, Portage was a tool that solved problems. It created new paradigms. It has evolved into something that while still cool, also enforces a paradigm that is hard to change and adapt to new problems.
Due to our use of subpop, much of metatools functionality is extensible via plugins. Plugins can be used to enhance the core functionality of the tool in a modular ‘plug-n-play’ way, reducing code bloat. Subpop also encourages a simple, microservices-style archictecture within the code itself. All this is very good for a complex problem like the automation of updates of packages for the world’s source code.