The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Принято решение по открытию Biicode, менеджера зависимостей ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Принято решение по открытию Biicode, менеджера зависимостей ..."  +/
Сообщение от opennews (ok) on 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.dev/opennews/art.shtml?num=41530

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Принято решение по открытию Biicode, менеджера зависимостей ..."  –3 +/
Сообщение от Аноним (??) on 24-Янв-15, 16:08 
Что, ты не хочешь вместо 1 пакетного манагера использовать 20 разных? Ну так не пользуйся виндой, а то козленочком станешь..
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

9. "Принято решение по открытию Biicode, менеджера зависимостей ..."  –1 +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 24-Янв-15, 16:22 
дебил, это не пакетный менеджер. И это гогно уже по факту второе.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

11. "Принято решение по открытию Biicode, менеджера зависимостей ..."  –1 +/
Сообщение от Вадик (??) on 24-Янв-15, 16:39 
А что было первым?
Я как-то упустил...
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

2. "Принято решение по открытию Biicode, менеджера зависимостей ..."  –2 +/
Сообщение от Аноним (??) on 24-Янв-15, 15:33 
В условиях того, что "индусы" клонируют библиотеку и вносят в нее правку, это может быть интересным.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

12. "Принято решение по открытию Biicode, менеджера зависимостей ..."  –1 +/
Сообщение от Аноним (??) on 24-Янв-15, 17:26 
в Go нет изкоробочного менеджера зависимостей. Там есть только команда "go get", клонирующая указанный репозиторий в папку $GOPATH/src
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

23. "Принято решение по открытию Biicode, менеджера..."  +3 +/
Сообщение от arisu (ok) on 24-Янв-15, 21:30 
> Да они и без интернета обходились, копируя библиотеки в проект с дискеты.
> Хотите вернуться в эти времена?

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

33. "Принято решение по открытию Biicode, менеджера..."  +1 +/
Сообщение от arisu (ok) on 25-Янв-15, 21:02 
дураков типа тебя пинаю.
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

25. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +1 +/
Сообщение от Аноним (??) on 24-Янв-15, 23:03 
> Да они и без интернета обходились,

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

4. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +3 +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 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.

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

37. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +/
Сообщение от Grammar_Nazi on 26-Янв-15, 09:32 
в безымянной
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Принято решение по открытию Biicode, менеджера зависимостей ..."  –5 +/
Сообщение от Аноним (??) on 24-Янв-15, 16:18 
хочу это.
Зарегистрировался
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +9 +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 24-Янв-15, 16:23 
а теперь ретвитни, сделай селфи себя с лого bii и не забудь написать об этом псто в fb
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

13. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +/
Сообщение от Аноним (??) on 24-Янв-15, 17:33 
кстати создатель Ruby Gems сейчас пилит Cargo для Rust, и это уже очень крутая вещь. Взять хотя бы воспроизводимые сборки.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

26. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +1 +/
Сообщение от Аноним (??) on 24-Янв-15, 23:04 
> кстати создатель Ruby Gems сейчас пилит Cargo для Rust,

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

17. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +/
Сообщение от V_ctor on 24-Янв-15, 18:40 
Объясните, это что-то типа мавена под жабу?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +/
Сообщение от Аноним (??) on 24-Янв-15, 20:13 
да, только в мавене зависимости прописываются в отдельном конфиге, а эта тулза парсит инклюды
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

40. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +/
Сообщение от anonymous (??) on 17-Авг-15, 13:05 
Это типа maven-репозитория. Зависимости по-другому разруливаются.
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

27. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +/
Сообщение от kravich (ok) on 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)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +/
Сообщение от Аноним (??) on 25-Янв-15, 04:52 
И как мы без этогого жили раньше?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +/
Сообщение от Аноним (??) on 25-Янв-15, 10:44 
И дальше будем жить. Ибо 10 штук пользователей им никогда не достичь, а это условие открытия.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

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

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

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

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

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

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

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

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

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


Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

39. "Принято решение по открытию Biicode, менеджера зависимостей ..."  +/
Сообщение от Ordu email(ok) on 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 и являлся все эти годы, начиная с момента своего рождения.

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру