URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 101298
[ Назад ]

Исходное сообщение
"Принято решение по открытию Biicode, менеджера зависимостей ..."

Отправлено opennews , 24-Янв-15 15:29 
Создатели проприетарного программного продукта Biicode (https://www.biicode.com/), в рамках которого развивается менеджер зависимостей и репозиторий пакетов для кода на языках  С/C++, сообщили (http://opensource.com/business/15/1/biicode-open-source-depe...) об утверждении решения по переводу Biicode в разряд свободных проектов. Biicode можно рассматривать в качестве адаптированного для С/C++ аналога систем Pip (Python), Gems (Ruby), cpan (Perl), npm (Node.js) и Pub (Dart), предоставляющих средства для доустановки необходимых для сборки проекта зависимостей, а также поддерживающих репозиторий для публикации пакетов.

По соглашению с инвесторами открытие кода Biicode будет произведено после того как число пользователей сервиса достигнет 10 тысяч. В настоящее время зарегистрировано (https://www.biicode.com/biicode-open-source-challenge) около 2500 аккаунтов. В рамках проекта Ryppl (https://github.com/ryppl/ryppl) уже предпринималась попытка создания подобного инструментария для C++, но проект последние несколько лет находится в заброшенном состоянии.


URL: http://opensource.com/business/15/1/biicode-open-source-depe...
Новость: http://www.opennet.me/opennews/art.shtml?num=41530


Содержание

Сообщения в этом обсуждении
"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено all_glory_to_the_hypnotoad , 24-Янв-15 15:29 
> Biicode можно рассматривать в качестве адаптированного для С/C++ аналога систем Pip (Python), Gems (Ruby), cpan (Perl), npm (Node.js) и Pub (Dart)

Совсем люди ебанулись.


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Аноним , 24-Янв-15 16:08 
Что, ты не хочешь вместо 1 пакетного манагера использовать 20 разных? Ну так не пользуйся виндой, а то козленочком станешь..

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено all_glory_to_the_hypnotoad , 24-Янв-15 16:22 
дебил, это не пакетный менеджер. И это гогно уже по факту второе.

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Вадик , 24-Янв-15 16:39 
А что было первым?
Я как-то упустил...

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Аноним , 24-Янв-15 15:33 
В условиях того, что "индусы" клонируют библиотеку и вносят в нее правку, это может быть интересным.

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Аноним , 24-Янв-15 15:34 
Для молодёжи ведь есть Go с подобной хренью. А олдскульщики С/C++ все равно не будут этим пользоваться.

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Аноним , 24-Янв-15 17:26 
в Go нет изкоробочного менеджера зависимостей. Там есть только команда "go get", клонирующая указанный репозиторий в папку $GOPATH/src

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено й , 24-Янв-15 21:26 
> "go get", клонирующая указанный репозиторий в папку $GOPATH/src

А также его зависимости, и всё это собирает. Вполне себе катит в роли

> изкоробочного менеджера зависимостей


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Нанобот , 24-Янв-15 20:44 
>А олдскульщики С/C++ все равно не будут этим пользоваться

вот-вот. суровые с/с++-разработчики тридцать лет обходились без такого, вряд ли сейчас они оценят этот гламур


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено й , 24-Янв-15 21:27 
> вот-вот. суровые с/с++-разработчики тридцать лет обходились без такого, вряд ли сейчас
> они оценят этот гламур

Да они и без интернета обходились, копируя библиотеки в проект с дискеты. Хотите вернуться в эти времена?


"Принято решение по открытию Biicode, менеджера..."
Отправлено arisu , 24-Янв-15 21:30 
> Да они и без интернета обходились, копируя библиотеки в проект с дискеты.
> Хотите вернуться в эти времена?

судя по тому, что творится с интернетами, которые с бешеной скоростью засираются хипстерами… идея выглядит уже не совсем бредовой.


"Принято решение по открытию Biicode, менеджера..."
Отправлено й , 25-Янв-15 13:02 
аргументация на уровне "книги дарьи донцовой плохие, давайте запретим и сожжем все книги"

ты-то сам что в интернете тогда делаешь, хипстор?


"Принято решение по открытию Biicode, менеджера..."
Отправлено arisu , 25-Янв-15 21:02 
дураков типа тебя пинаю.

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Аноним , 24-Янв-15 23:03 
> Да они и без интернета обходились,

Прикинь, в отличие от хипстоты у них не падает вообще все если сеть недоступна :).


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено й , 25-Янв-15 13:05 
>> Да они и без интернета обходились,
> Прикинь, в отличие от хипстоты у них не падает вообще все если
> сеть недоступна :).

пользователи svn в треде?


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено all_glory_to_the_hypnotoad , 24-Янв-15 15:37 
Вообще какое-то невменяемое дерьмище вроде пыховских костылей:

> #include "google/gtest/gtest.h"
> You don’t need “googletest” in your system, it is already in biicode
> bii find It looks for the required libraries in biicode, in this case, googletest. Once found, it downloads the required source code files into one folder of your project and configures everything.

Зашибись.. А если случайно произойдёт наложение имён, то оно похерит проект, или просто будет скачивать всякое гогнище в проект.

Вердикт: закопать вместе с авторами в безимянной могиле.


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Анонимускодер , 24-Янв-15 22:25 
> Вообще какое-то невменяемое дерьмище вроде пыховских костылей:

Скачает что-то, какой-то версии и поместит это в какой-то каталог. Совсем мозги скурили.


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Grammar_Nazi , 26-Янв-15 09:32 
в безымянной

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Аноним , 24-Янв-15 16:18 
хочу это.
Зарегистрировался

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено all_glory_to_the_hypnotoad , 24-Янв-15 16:23 
а теперь ретвитни, сделай селфи себя с лого bii и не забудь написать об этом псто в fb

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Аноним , 24-Янв-15 17:33 
кстати создатель Ruby Gems сейчас пилит Cargo для Rust, и это уже очень крутая вещь. Взять хотя бы воспроизводимые сборки.

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Аноним , 24-Янв-15 23:04 
> кстати создатель Ruby Gems сейчас пилит Cargo для Rust,

Хорошее название, намекает про детишек с Cargo-культом и модными языками. И софтом из бамбуковых палок.


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено V_ctor , 24-Янв-15 18:40 
Объясните, это что-то типа мавена под жабу?

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Аноним , 24-Янв-15 20:13 
да, только в мавене зависимости прописываются в отдельном конфиге, а эта тулза парсит инклюды

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено bav , 24-Янв-15 20:14 
> Объясните, это что-то типа мавена под жабу?

Нет это что-то будет ломать проект если библиотека обновится.


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено anonymous , 17-Авг-15 13:05 
Это типа maven-репозитория. Зависимости по-другому разруливаются.

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено kravich , 25-Янв-15 04:32 
What's pip? A package manager. How do I get it? Use easy_install. What's easy_install? A package manager. How do I get it? Use apt. (c)

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Аноним , 25-Янв-15 04:52 
И как мы без этогого жили раньше?

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Аноним , 25-Янв-15 10:44 
И дальше будем жить. Ибо 10 штук пользователей им никогда не достичь, а это условие открытия.

"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Куяврег , 25-Янв-15 13:35 
дело идёт к тому, что на системные зависимости и пакетный менеджер всем будет наплевать. ничего не напоминает? некую систему, где библиотеки размещены в строгом порядке "кто где наср#$%л", каждая софтина имеет свой инсталлятор, свой обновлятор (если имеет), тащит за собой то, к чему её приколотили гвоздями.

выглядит как линуксокапец, но оптимизм внушает две вещи.
- ушлёпки с таким стилем программирования написать под несколько дистров не осиливают.
- фрагментация дистров оставляет варианты для тех, кому не надо из системы делать отхожее место.


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Ordu , 25-Янв-15 22:28 
Вы слишком поспешно переходите к выводам. Пакетные системы, функционирующие параллельно с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake. И унифицированная система сборки для, допустим, проектов на C++ может оказаться весьма удобной для строителей дистрибутивов. Ну, во-всяком случае, примеряя всё это к gentoo, я скажу, что можно конечно запилить пакетный менагер, которым неудобно пользоваться из ебилда и проще реализовать всю логику сборки и инсталляции заново, но если есть хотя бы 700 граммов мозга и общая эрудиция в отношении методов распространения софта в *nix системах, то вполне возможно создать пакетный менагер, который будет реальным подспорьем для мейнтейнеров дистрибутивов, а не чем-то в стиле "не пришей кобыле хвост." Да и для меня оно может оказаться удобным, в том смысле, что чем проще ебилды, тем проще их править, если мне вдруг потребовалось что-то особенное -- это значит что мне меньше придётся ставить всякого дерьма в обход emerge в домашнюю директорию или в /usr/local.

Чтобы делать какие-либо выводы из новости, надо подождать и посмотреть. Не знаю как вы, а я ничего не знаю об этой системе сборки. Я даже по ссылкам на офсайт не переходил, чтобы почитать страничку озаглавленную как About или как WTF, потому что более чем уверен, что ещё не время для выводов и к разработке на C++ я не имею никакого отношения. Но если вы знаете больше, и это больше действительно выглядит ужасно, то не стесняйтесь, поделитесь с нами.


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено all_glory_to_the_hypnotoad , 26-Янв-15 00:05 
> Пакетные системы, функционирующие параллельно с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake

Идиот безмозглый, autotools это не пакетная система.


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Ordu , 26-Янв-15 02:13 
>> Пакетные системы, функционирующие параллельно с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake
> Идиот безмозглый, autotools это не пакетная система.

Расскажите ещё что-нибудь об autotools, у вас очень занимательно выходит.


"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Куяврег , 28-Янв-15 00:17 
> Вы слишком поспешно переходите к выводам. Пакетные системы, функционирующие параллельно
> с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake.

o_O по моим сведениям использование autoconf/automake не приводит к появлению в системе библиотек, неизвестных пакетному менеджеру системы, сами не ведут никакого учёта установленного и сторого говоря пакетным менеджером не являются. во всяком случае в портах и портежах это далеко не так. Я не спорю, что при горячем желании это можно сделать, но пока я не видел таких решений. А вот упомянутые pip/gems/cpan - видел, и применяются они ровно так, как не надо.

>[оверквотинг удален]
> к gentoo, я скажу, что можно конечно запилить пакетный менагер, которым
> неудобно пользоваться из ебилда и проще реализовать всю логику сборки и
> инсталляции заново, но если есть хотя бы 700 граммов мозга и
> общая эрудиция в отношении методов распространения софта в *nix системах, то
> вполне возможно создать пакетный менагер, который будет реальным подспорьем для мейнтейнеров
> дистрибутивов, а не чем-то в стиле "не пришей кобыле хвост." Да
> и для меня оно может оказаться удобным, в том смысле, что
> чем проще ебилды, тем проще их править, если мне вдруг потребовалось
> что-то особенное -- это значит что мне меньше придётся ставить всякого
> дерьма в обход emerge в домашнюю директорию или в /usr/local.

...и с этим сложно спорить. Да, теоретически можно так и сделать. И если кто-то реализует - вполне возможно кому-то такое понадобится. И если будет работать отлично - так ещё один source-based с унифицированной системой сборки, она же пакетный менеджер - не останется без аудитории. Но пока это теоретические выкладки.

> Но если вы знаете больше, и это больше действительно выглядит ужасно, то не стесняйтесь, поделитесь с нами.

Степень ужасности зависит ровно от применения. Сам молоток не является ужасным, но если его держат за боёк и забивают рукоятью - это ужасно. Так что если оно будет применяться в качестве единственного менеджера пакетов - это нормально (хотя и бесполезно для остальных). Если подобно cpan/gems в портах/портежах - это выглядит ужасно. Да, и будем честными, не только выглядит. Это и есть ужасно.



"Принято решение по открытию Biicode, менеджера зависимостей ..."
Отправлено Ordu , 28-Янв-15 00:37 
>> Вы слишком поспешно переходите к выводам. Пакетные системы, функционирующие параллельно
>> с системным пакетным менагером, существуют очень давно. Вспомнить тот же autoconf/automake.
> o_O по моим сведениям использование autoconf/automake не приводит к появлению в системе
> библиотек, неизвестных пакетному менеджеру системы, сами не ведут никакого учёта установленного
> и сторого говоря пакетным менеджером не являются. во всяком случае в
> портах и портежах это далеко не так. Я не спорю, что
> при горячем желании это можно сделать, но пока я не видел
> таких решений. А вот упомянутые pip/gems/cpan - видел, и применяются они
> ровно так, как не надо.

Вы видели как порты и портежи используют pip/gems/cpan? Примерно так же как и autoconf/automake. Нет, я понимаю, что вас раздражает -- я назвал autoconf/automake пакетным менагером, вы же при этом считаете, что отслеживание зависимостей, установленных файлов, конфликтов между файлами и прочие функции -- неотъемлимыми атрибутами пакетного менагера, без которых он совсем не менагер. Мы можем поспорить на этот счёт, если вы хотите, но это будет терминологический спор, исход которого никак не изменит истинности/ложности того, что было сказано мною -- в худшем случае, мне придётся подредактировать то моё сообщение и заменить там слова "пакетный менагер" на какое-то другое собирательное слово/слова, которые будут означать множество софта, включающее в себя и pip/gems и autotools.
Мне совершенно не хочется спорить о какой-то туфте типа слов. Слова -- это просто способ сотрясать воздух, спорить из-за них глупо. Давайте считать, что я проиграл спор, но при одном условии: дайте мне этот собирательный термин, который я смогу воткнуть вместо "пакетного менагера". Я отредактирую то своё сообщение, приведу его к нераздражающему вас виду, и ещё оставлю покаянный постскриптум, с пояснением внесённой правки.

> ...и с этим сложно спорить. Да, теоретически можно так и сделать. И
> если кто-то реализует - вполне возможно кому-то такое понадобится. И если
> будет работать отлично - так ещё один source-based с унифицированной системой
> сборки, она же пакетный менеджер - не останется без аудитории. Но
> пока это теоретические выкладки.

Практически, всё сведётся к тому, что появится ещё один eclass, который позволит в две строчки кода укладывать ебилды для софта использующего biicode. Может быть даже появятся скрипты, которые будут генерировать эти самые ебилды, на основании конфига проекта. Неплохо было бы, м? Держать /usr/local/portage в когерентном состоянии стало бы ещё проще.

> Степень ужасности зависит ровно от применения. Сам молоток не является ужасным, но
> если его держат за боёк и забивают рукоятью - это ужасно.
> Так что если оно будет применяться в качестве единственного менеджера пакетов
> - это нормально (хотя и бесполезно для остальных). Если подобно cpan/gems
> в портах/портежах - это выглядит ужасно. Да, и будем честными, не
> только выглядит. Это и есть ужасно.

Подробнее можно? Вас не устраивает то, что ebuild'ы для ruby-софта оказываются обёртками над gem? А когда эти ebuild'ы -- обёртки над autoconf/automake? Это тоже не нравится? Почему?

Мне кажется это замечательно -- есть куча средств сборки и установки софта, и ebuild при таком подходе становится мета-средством установки софта, которое унифицирует интерфейс, прячет различия, приводит всё к общему знаменателю. Собственно то, чем этот ebuild и являлся все эти годы, начиная с момента своего рождения.