The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for MCUs 1.5, opennews (??), 29-Окт-20, (0) [смотреть все]

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


22. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  +/
Сообщение от Ilya Indigo (ok), 29-Окт-20, 14:40 
Ну вот зачем он нежен, да ещё и на пихоне!
rpm их чем не устраивает?
Ответить | Правка | Наверх | Cообщить модератору

24. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  –1 +/
Сообщение от Аноним (98), 29-Окт-20, 14:48 
> rpm их чем не устраивает?

"сделано не ими" (с)

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

32. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  –1 +/
Сообщение от Аноним (29), 29-Окт-20, 15:59 
>Ну вот зачем он нежен, да ещё и на пихоне!

Мсье желает по жестче? Как на счет %вставить_очередную_шутку_про_раст%?

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

33. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  –4 +/
Сообщение от m.makhno (ok), 29-Окт-20, 16:04 
RPM нежный?)
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

52. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  –1 +/
Сообщение от анонимуслинус (?), 29-Окт-20, 20:36 
очень, особенно когда база блокируется и потом сыпется. тебе нежно потом намекают, что кабздец полный и ты волен заниматься make install вечно постигая дзен.))
Ответить | Правка | Наверх | Cообщить модератору

34. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  +/
Сообщение от Аноним (34), 29-Окт-20, 16:32 
C++ разработчики тоже люди и хотят нежности.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

59. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  +2 +/
Сообщение от Аноним (58), 29-Окт-20, 22:54 
Тогда пора переходить на Раст. Плюсы после него - неудобный мусор. Уже и не говорю и си, который на фоне плюсов - беспомощный тонущий щеночек.
Ответить | Правка | Наверх | Cообщить модератору

99. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  –1 +/
Сообщение от Аноним (99), 31-Окт-20, 17:45 
Хорошая попытка, анон.
Ответить | Правка | Наверх | Cообщить модератору

40. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  +/
Сообщение от Аноним (-), 29-Окт-20, 18:19 
Я тоже за нежный пихон. А рпм слишком груб.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

62. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  +3 +/
Сообщение от Ordu (ok), 29-Окт-20, 23:25 
> rpm их чем не устраивает?

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

И я не буду каждый раз, когда мне хочется добавить printf в недра библиотеки собирать новый rpm-пакет. Я даже не вижу смысла общесистемно ставить эту библиотеку: я её проще так подключу, модифицировав LD_LIBRARY_PATH. Или даже прилинкую статически к своему проекту, чтобы не возиться с переменными окружения.

Я не буду всего этого делать, и уж тем более я не буду ждать, когда мейнтейнеры дистра пошевелятся и занесут в репы интересную мне версию библиотеки. Или хотя бы хоть какую-нибудь версию библиотеки занесут в репы. Когда-то я пробовал пользовать тематические оверлеи для gentoo, под common-lisp например, точно использовал, но на это я тоже забил, потому как эти оверлеи имеют тенденцию забывать обновляться на полгода или даже на пару лет, и из-за этого становится бесполезными.

> Ну вот зачем он нежен, да ещё и на пихоне!

А на чём его писать? На bash что ли? На bash довольно неудобно парсить конфиги, их конечно можно писать в синтаксисе bash, но нафиг надо, если конфиги можно писать в toml или в json, и парсить из python'а двумя строчками, одна из которых начинается со слова import. То есть, можно конечно написать и на bash, но видимо это не надо никому, кроме тебя.

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

64. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  –1 +/
Сообщение от Ilya Indigo (ok), 29-Окт-20, 23:36 
Благодарю за разъяснение.
Из текста новостей про Qt6 не понятно было что именно это такое и зачем это нужно.
> А на чём его писать? На bash что ли?

На C++.

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

83. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  +/
Сообщение от Котофалк (?), 30-Окт-20, 12:31 
> я хочу иметь возможность использовать даже не версию библиотеки, а конкретный git-commit

вам к source-based, портежи умеют в это.

> Когда-то я пробовал пользовать тематические оверлеи для gentoo, под common-lisp например

о, вы только что оттуда.

Ну так-то да, но от схемы с оверлеями "собственный пакетный менеджер Qt" отличается только тем, что какие-то базовые репы там будут тянуть силами разрабов Qt и есть шанс что их не бросят. Или есть ещё отличия?

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

90. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  +/
Сообщение от Ordu (ok), 30-Окт-20, 17:39 
>> я хочу иметь возможность использовать даже не версию библиотеки, а конкретный git-commit
> вам к source-based, портежи умеют в это.

Ты пробовал это применять на практике? Я тебя заверяю, гораздо проще жить, имея в дереве проекта файлик toml, в котором депенданс описывается тремя строками, и смена номера версии на коммит git'а сводится к редактированию одной строки. Чтобы в оверлей добавить описание ещё одной версии пакета, надо создать копию ebuild'а (или даже создать с нуля его, потому что нечего копировать), подредактировать ebuild, подписать ebuild, собрать ebuild. При этом, собираться он будет в /var/tmp, даже если мне было бы удобно собирать в ~/home, после сборки дерево сорцов будет удалено. Он будет поставлен общесистемно -- и если у меня уже стоит такая библиотека в системе, то либо она будет заменена, либо мне придётся в ебилде возиться с multilib. При этом всегда остаётся риск, что что-то пойдёт не так, и я, устанавливая ещё одну версию qt, запорю установленную, и у меня половина софта прекратит запускаться, в результате чего, я ещё полдня проведу не за разработкой, а за восстановлением системы.

Да, если повозиться с emerge/ebuild, то всё же можно сделать, но хорошо не получится из-за того, что придётся возиться с emerge/ebuild. Серьёзно так возиться, с каждым ebuild'ом, и с каждым прецедентом пересборки моего проекта. С учётом того, что альтернатива -- это вписать пару строк в .toml и всё заработает, отказ от ebuild однозначно полезная вещь.

>> Когда-то я пробовал пользовать тематические оверлеи для gentoo, под common-lisp например
> о, вы только что оттуда.
> Ну так-то да, но от схемы с оверлеями "собственный пакетный менеджер Qt"
> отличается только тем, что какие-то базовые репы там будут тянуть силами
> разрабов Qt и есть шанс что их не бросят. Или есть
> ещё отличия?

Отличия есть де факто. Глянь на npm, pip, gem, cargo, quicklisp: они работают, в отличие от тематических оверлеев gentoo. Вот что это за различия, которые позволяют получить работоспособность -- это более сложный вопрос. Я полагаю дело в том, что разработчику проекта максимально упрощается задача создания "пакета", который может быть автоматически скачан вместе со всеми депендансами и собран.

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

107. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  +/
Сообщение от Котофалк (?), 23-Дек-20, 15:04 
> Ты пробовал это применять на практике?

Да

И да, смена номера коммита приводит к редактированию одной строки. Либо в ебилде библиотеки, либо в ебилде. "Создать ебилд" конечно посложнее.

> после сборки дерево сорцов будет удалено.

нет. после сборки - нет. после установки в систему (ebuild ... merge)

> Он будет поставлен общесистемно

нет. ebuild ... install ставит в песочницу.

Ещё замечание: часть проблем ты описываешь которые суть "смешивание рабочей и сборочной среды". если подразумевать, что сборочная среда (даже в минимальном chroot-воплощении) от рабочей отделена, проблем нет.

> лянь на npm, pip, gem, cargo, quicklisp: они работают, в отличие от тематических оверлеев gentoo.

это вопрос дискуссионный. я видел всякое, например рекурсивные ошибки в gem.

> Я полагаю дело в том, что разработчику проекта максимально упрощается задача создания "пакета", который может быть автоматически скачан вместе со всеми депендансами и собран.

всё верно. но зачастую результатом gem/pip/cargo etc является то, что сборочная среда называется рабочей и отправляется пользователю в продакшен. это как раз то, что как пользователю мне не нравится.

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

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

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

Чехарда с "пакетными менеджерами для каждого языка" даёт тактический выигрыш, но это совершеннейший стратегический тупик. Ну или как вариант - отказ от концепции операционной системы вообще, что-то типа предельного развития концепции  qubernetes

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

108. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  +/
Сообщение от Ordu (ok), 23-Дек-20, 15:55 
>> Я полагаю дело в том, что разработчику проекта максимально упрощается задача создания "пакета", который может быть автоматически скачан вместе со всеми депендансами и собран.
> всё верно. но зачастую результатом gem/pip/cargo etc является то, что сборочная среда
> называется рабочей и отправляется пользователю в продакшен. это как раз то,
> что как пользователю мне не нравится.

А это не проблемы разработчика. Разработчик может собрать appimage какой-нибудь, и дать пользователю бинарь. Это ок, и этот бинарь никак не зависит от сборочной среды. Либо разработчик может дать пользователю всё вместе со сборочной средой -- бери и собирай вручную. Но думать о том, как правильно интегрировать софтину в тот или иной дистр -- это не проблема разработчика. Это проблема мейнтейнера. Не, если мейнтейнер ко мне обратится, и объяснит свои проблемы, я, скорее всего, совершу какие-нибудь телодвижения, которые сделают его задачу проще. Но по своей инициативе я не полезу разбираться с тем, как в разных дистрах обустроена установка софта.

Я к тому, что мне как разработчику, нужны инструменты для разработки. Мне удобен git для разработки? Я использую git. Мне удобен cargo, я использую cargo. Я не собираюсь отказываться от удобных инструментов, в пользу тех костылей, которые "продакшн" использует для сборки.

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

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

Пользователь хочет сказать что-то типа "возьми версию софтины x.y.z, скачай её, посчитай депендансы, докачай чего не хватает, обнови что надо обновить, собери и поставь. И чтоб всё работало".

Разработчик же часто жонглирует сырыми кусками кода, ему совершенно не нужно ставить софт в систему -- ещё не хватало, чтобы каждый раз когда я скачиваю библиотеку, чтобы посмотреть что она из себя представляет, у меня бы пересобиралась половина системы и потом ещё и не работало бы. Мне нужно _чёткое_ разделение системного пакетного менагера, и рабочего. Если рабочий мне собирает всё в build директории проекта, включая и депендансы тоже -- то это очень удобно, я потом сделаю rm -rf на этом build'е, и удалю всё к чертям. Если рабочий пакетный манагер выкачивает мне зависимости только под этот проект, не оглядываясь на системно-установленный у меня софт -- это удобно, это даёт мне рабочее окружение, которое минимально отличается от рабочих окружений других разработчиков, которые могут сидеть на других дистрибутивах, и при этом может они последние три года забывали обновлять софт.

Более того, для разных языков программирования нужны разные пакетные менагеры, потому как в них по-разному всё происходит. Если начать пихать в один пакетный менагер всё, что может понадобиться любому, то получится такая хрень, что через неё не продерёшься. Ты не читал историю языка программирования PL/1? В него попытались напихать всё-всё-всё. Кончилось это провалом. В Common Lisp'е довольно часто наблюдается попытка напихать в библиотеку все-все-все возможности, в результате получается ТАКОЕ, что сам чёрт ногу сломит. Это общий инженерный принцип: надо всегда решать конкретную задачу. Чем более конкретную, тем лучше. Неконкретная попытка "сделать хорошо всем" кончается кучей навоза.

> Чехарда с "пакетными менеджерами для каждого языка" даёт тактический выигрыш, но это совершеннейший стратегический тупик. Ну или как вариант - отказ от концепции операционной системы вообще, что-то типа предельного развития концепции  qubernetes

Ты путаешь пакетные менагеры и пакетные менагеры. Есть системный пакетный менагер, есть пакетный менагер разработчика. Они разные и для разных целей созданы. Пакетный менагер разработчика, между прочим, делает жизнь мейнтейнера дистрибутива проще: глянь на те же autotools. ebuild в gentoo отлично пользуется autotools, делигируя им собственно сборку, но забирая себе такие задачи как копирование файлов в систему. Ничто не запрещает разработчикам ebuild'а связаться с разработчиками cargo, и объяснить свои нужды: в какие задачи выполняемые cargo им надо вмешаться, и что сделать иначе. А потом написать eclass, и может пачку скриптов, которые взаимодействуя с cargo напишут заготовку ebuild'а. Но, ты ж понимаешь, это не задача разработчиков cargo решать как лучше будет для мейнтейнеров gentoo? Скажем, надо ли в ebuild'е для растовой программы выписывать растовые депендансы? Или не надо? Может только C'шных депендансов хватит, которые как dll используются?

Разработчики gentoo в состоянии свой ebuild заточить под разные компиляторы? Почему они не могут заточить его под разные системы сборки?

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

68. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  +1 +/
Сообщение от Аноним (68), 30-Окт-20, 01:33 
> пихоне

желаю его осуществления, в виде игл тебе под ногти

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

88. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  +2 +/
Сообщение от niger (??), 30-Окт-20, 16:52 
Пакетный менеджер в языки и фреймворки тянут для несчастных и убогих виндузятников у которых ничего нет. И у них да, проблема лишнюю библиотеку поставить. Убиться можно.

А в нормальных дистрах да, есть пакетные менеджеры, есть порты и т.д.

Всёравно ни в одной серьёзной компании делающей серьёзный софт служба безопасности не пропустит эти пакетные менеджеры. Иш ты, ещё дай возможность девелоперам все подряд тянуть.

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

102. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."  +/
Сообщение от банан (?), 01-Ноя-20, 08:48 
> А в нормальных дистрах да, есть пакетные менеджеры, есть порты и т.д.

Использование пакетного менеджера не даёт выбрать версию зависимости. Вы хоть убейтесь, вы не сможете положить в пакет дистрибутива такую версию ангуляра (к примеру), которая устроит всех. И вы не заставите гугл поставлять тот же самый ангуляр во все дистрибутивы правильно.

А если у вас пять версий приложения, каждую из которых необходимо собирать со своей совокупностью версий зависимостей?

Возможно это говорит о том, что динамика поставки библиотек (пакетов, зависимостей, крейтов, нугетов) со временем меняется в худшую сторону.

Вот и появляются флетпаки, пакетные менеджеры и прочее.

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

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

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




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

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