Comments 31
Это разве удобнее, чем с образом виртуальной машины?
Если вы имеете ввиду какой-нибудь .ova (например для virtualBox), то на мой взгляд нет:
Есть тормоза и задержки (даже на хорошем компуторе). Как я не пытался прокидывать драйвера видеокарты, у меня не получалась безупречная скорость отклика, как с докера. Вероятно дело в том что там активно целое десктоп окружение в довесок
Обновление версии = скачать новый бинарный экспорт .ova, например 10гб (оптимистично). Снимки (snapshot вроде?) поддерживаются только на машине где они были сделаны и не экспортируются для других пользователей.
намного, с точки зрения пользователя.
Быстрее во всем смыслах, и экономит память.
https://www.vagrantup.com/ не подошёл? Когда-то через него настраивали среду как раз для c++ .
В креаторе уже есть зачаточная поддержка разработки в докере, аналог дев контейнеров. Год назад я это щупал. Не знаю насколько продвинулись в этом направлении.. Если допилят до состояния как в VSCode, тогда можно будет не изобретать такое.
Я бы хотел иметь команду навроде docker check IMAGE_NAME latest
Можно с помощью crane или skopeo узнать дайджест образа в регистри без полного скачивания. Ну или даже curl-ом, дайджест в заголовке надо будет словить.
Так и не понял, что мешает юзать vsc для данного кейса
Это из разряда мечтаний. Qt-специфичные технологии имеют лучшую поддержку в IDE, внезапно, QtCreator :) И обеспечивать поддержку этим приблудам в vsc желания мало, с учетом того что из коробки в QtCreator они есть.
Например в vsc лучше обертка над отладчиком (ИМХО), на уровне расширений больше вариантов по созданию шаблонов продуктов, намного понятнее механизм создания своих расширений, ну и в целом сообщество намного больше со всеми вытекающими.
Но этого недостаточно на текущем уровне, когда вся эта история с IDE, исключительно моя инициатива и держится только на энтузиазме. Выхлоп будет несопоставим трудозатратам, так я это оценил, когда с кавалерийского наскока попробовал получить в vsc уровень комфорта QtCreator со стеком Qt + QML + C++
Ну вы же в курсе вот этого? https://marketplace.visualstudio.com/items?itemName=TheQtCompany.qt-ui
Огромный ответ безо всякой конкретики. Я работал (и продолжаю работать) с Qt/QML в VS, VSC, QtC. И вот что-то понять не могу, чем же он (QtC) так хорош, что ради него надо так заморачиваться
Красивое из коробки отображение QString и прочих кутешных классов в отладчике (в vscode есть конечно возможность подгрузить преттипринтеры для Qt). QML и Widgets дизайнер. Дополнение в QML коде. Удобная сборка и деплой приложения под Андроид.
Это я навскидку вспомнил..
Дизайнер юзал только на этапе изучения Qt, ибо в сложном приложении, особенно QML, этот самый дизайнер бесполезен, быстрее руками набросать всё, что надо. Красивое отображение QString? При уродливой отладке? Такой себе плюс. Сборка приложений под андроид есть, ок. Только вот целевые системы - это линукс и винда )
Вспоминайте ещё
вот побольше конкретики плюсом к тому, что написал @navrocky
Это не описано в статье, но
QC в дереве проекта от сборочной системы qbs имеет полезное контекстное меню, которым я регулярно пользуюсь (добавление продуктов, добавления файлов в ресурсы qrc, ...). В единственном расширении VSC на qbs контекстного меню нет совсем, эти фичи пришлось бы делать по другому, либо допиливать расширениеВ проекте используем кастомные wizard. В VSC есть расширения такого плана, но нужно было бы всё на них переделать
Это не описано в статье, но
Подавляющее большинство коллег работают на QC. Мое решение с порога было бы сильно менее популярное для общественности и скорее всего только я один бы этим пользовался, будь базой VSC.Qt-шная документация в формате .qch. Я не нашел способа отображать ее в VSC. В QC по F1 на каком-либо символе мгновенно получаешь доку
p.s. я не говорю что невозможно использовать VSC как среду под описанный стек, но в моих условиях QC смотрелся выигрышнее, как быстрое и не сильно ломающее традиции, решение
А у вас QBS? Если нет, то зачем притягивать за одно место? Если да, то очень жаль... Есть CMake, но кому-то упорно хочется есть кактус.
А можно подробнее про кастомные визарды? Ну чисто для общего развития. А то я сосем не понимаю, о чём речь
Берем винду. Берем WSL. Докер не ставим, ибо он всё равно работает через WSL. Разворачиваем образ. Запускаем QtC из под WSL, и работаем как с обычным окном в винде. Костыли free )
В жизни не читал её таким способом. Google->название нужного класса.
Про традиции опять понятно... Не хочется вылазить из скорлупы. А вот когда появляется несколько проектов или RFP, один под винду, другой под линукс, то сильно между системами не набегаешься. И ждать нужную машину от саппорта не будешь... Хотя некоторые так и делают ).
Перечитал ещё раз ваши вводные. И вообще не могу понять, зачем такую дичь творить. Win+WSL+VSC. Всё работает сразу, везде, и из коробки
У меня нет предпочтения к Win как к рабочей системе, но допустим. В крайнем случае в этом выражении Win+WSL можно заменить на какой-нибудь хостовый линукс и получится что-то например Ubuntu+VSC
Как у вас обеспечивается переносимость такого рабочего окружения между компьютерами?
У вас написано, что у вас кроссплатформенная разработка? причём винда там не для галочки. При этом вы избегаете винды. Это как понимать? Тем более если предоставляется удобный инструмент, зачем от него отказываться в пользу костылей?
Вы при желании можете просто запустить QtC внутри WSL и всё. Тут тоже никаких костылей не нужно.
И про какую переносимость речь? Вы хотите распространять в докере? Ну так делайте это, это не проблема. Вы хотите работать на 100500 компах? Тут опять вопрос... А зачем? У меня для всех разработок (кроме мака) всего одна машина на винде. Нужен доступ - пожалуйста, RDP
По вашему ответу вы как будто любой ценой стремитесь юзать докер, ибо это тру. У меня был такой разработчик, который golang проект под винду хотел почему-то разрабатывать на линуксе, и именно в докере. И в итоге код не писал, только страдал.
у меня есть вынуждено-развернутое окружение проекта под винду, на домашнем ПК и иногда (пару раз в квартал) я использую его для решения редких специфичных задач, где платформа играет роль. Но это не значит, что я хотел бы сидеть на ней всегда, как я уже сказал, у меня нет личного предпочтения к Win. Так что да, я избегаю винды
В статье упомянул, что распределение рабочих компов примерно 50 на 50 (win, linux), плюс тестируют также на разных платформах, так что у меня нет вынужденной необходимости всегда держать под рукой win окружение
Вы при желании можете просто запустить QtC внутри WSL и всё
Да, как и могу запустить его на хост-линуксе. Но смысл именно в том, чтобы собрать в пакет утилиты, определенные зависимости, настройки разных конфиг файлов, ... И собственно иметь переносимое рабочее окружение, которое шарится не только между моими рабочими компами, но и с коллегами.
Этим стабильно пользуется 10-15 человек, потому что с нуля настраивать окружение долго, а у меня в рабочей документации четкая инструкция по которой можно за 5 минут получить полностью настроенную IDE с комплектом, подвязанными дебагерами, сборочной системой нужной версии, шаблонами создаваемых продуктов, сниппетами, собранной под Qt комплект утилитой интроспеции Qt приложений, ... и многое многое другое. За 5 минут реального времени с вычетом пассивного ожидания скачивания образа.
Могли бы не писать столько. Просто написали бы, что из принципа - и всё понятно. Отсюда и куча противоречий. То у вас каждый разработчик индивидуальность, и хочет работать со своим окружением, то вы насильно впихиваете каждому инструкцию инструкцию по костылям (нифига она не на 5 минут) и впихиваете каждому не особо удобную IDE.
Может, стоило направить энергию в более полезное русло, например, сделать так, чтобы проект не надо было разворачивать год ). Хотя я сомневаюсь в этом, мне кажется, вы сгущаете краски.
Но по итогу приходим к тому же... Вместо того, чтобы юзать простой удобный инструмент, вы из принципа городите костыли. Знал такого человека, знал ))
То у вас каждый разработчик индивидуальность
Такого тезиса в статье не было. Есть легкая кастомизируемость контейнера, но это мелочи. В основном все юзают QC и не с моей подачи
вы насильно впихиваете
Каюсь, такое есть. В этом смысле я фанатик. Но у людей все равно есть выбор, и мне приятно, что много людей посчитали это удобным для каждодневного использования в рабочих задачах
нифига она не на 5 минут
Инструкция сильно меньше статьи. В статье отразил ход мыслей в процессе создания и с какими проблемами сталкивался. В боевой инструкции на голую систему 6 шагов, 4 из которых просто копипаст команд в терминал (установка докера, подтягивание скриптов запуска с репозитория, ...). 5 минут это для того кто делает в первый раз, я для интереса прогонял за 1 минуту.
проект не надо было разворачивать год
про год речи нигде не было. 1-2 дня.
Развернуть чтобы просто скомпилировалось это одно, это условно "быстро"
Развернуть с учетом всего накопленного полезного инструментария, специфичных настроек, ... уже долго
Вместо того, чтобы юзать простой удобный инструмент, вы из принципа городите костыли
Изначально работал как вы и говорите, QC на хосте. Но неоднократно столкнувшись с проблемами, описанными в статье, нашел для себя такое решение. Оно оказалось настолько удобным, что больше QC на хосте у меня не бывал. И не одному мне полезно - как я уже говорил, многие коллеги пользуют на постоянку.
и мне приятно, что много людей посчитали это удобным для каждодневного использования в рабочих задачах
Всё познается в сравнении )
про год речи нигде не было. 1-2 дня.
Это и имелось ввиду. И я пока не видел другой причины для этого, кроме как плохая структура проекта.
Изначально работал как вы и говорите, QC на хосте. Но неоднократно столкнувшись с проблемами, описанными в статье, нашел для себя такое решение. Оно оказалось настолько удобным, что больше QC на хосте у меня не бывал. И не одному мне полезно - как я уже говорил, многие коллеги пользуют на постоянку.
Вы под каждый проект будете такой огород городить? А смысл? Вот у меня на компе куча IDE, несколько СУБД и тд... Прилетает проект или запрос, а окружение уже есть. И не в каждом плюсовом проекте есть Qt, не говоря уже о том, что не всегда это плюсы. И если проект не требует явно той или иной IDE, то юзать надо универсальное решение, потому что тупо проще, чем скакать по IDE
Ещё, как вариант, в докере можно поднять Xvnc, простенький рабочий стол с IceWM или чем-то подобным, получается практически виртуалка. А если ещё прикрутить к этому NoVnc (https://github.com/navrocky/novnc-docker) то вообще можно из браузера туда ходить, работать удалённо.
Пробовали ли Вы flatpack или snap? Какие были недостатки с ними?
MSYS2 под фоточками решило мои проблемы.
Рабочая C++ IDE в docker container