IDE и docker

Ctrl-F, «ssh» первое найденное вот: IDE и docker (комментарий) рекомендация ssh из ide в контейнер то ли средствами ide то ли для sshfs.

Чего только ни придумают, лишь бы не наводить порядок.

сраный трешак

Такова жизнь.

ssh из ide в контейнер

Да. После этого ты дальше работаешь над своим кодом уже в контейнере, где есть все инструменты и зависимости.

За подробностями в гугл по «devcontainers», хотя и в этой теме кто-то писал, в двух словах, как работает удалённая разработка в VSCode.

Лучше вот это https://code.visualstudio.com/docs/devcontainers/containers

Оно же там по ссылке дальше.

докер со средой сборки, которая неизменна как основа капитализьма, проекта - правильно.
проект прикладывается снаружи, он редактируется.
зачем изменяемое (код, заголовки, текста и прочее) упаковывать в докер ??

CLion из коробки умеет собирать и запускать приложение в докере. При настройке тулчейна указываешь имя докер образа и всё начинает работать внутри контейнера.

Я и не говорил что исходники проекта в докере. В докере некоторые части платформы, которые нужны для сборки проекта.

вытащи и подключи снаружи или продублируй.

Ну да, конечно. А потом "вытащи и подключи снаружи сисрут, а потом «вытащи и подключи снаружи систему сборки». Мог бы просто сразу написать «не используй докер».

зачем изменяемое (код, заголовки, текста и прочее) упаковывать в докер ??

Это и не упаковывается в докер - директория с исходниками проекта и прочим лежит в хостовой системе и просто монтируется в контейнере. Фактически контейнер просто содержит компиляторы, стандартные include-файлы и прочую среду сборки, совместимую с production-средой выполнения программы.

ну дык и я про тоже !! %тс% я так понимаю «стандартные инклуды» нужны снаружи.
значится надобно их вытащить наружу и снаружи подключить внутре докера.
либо продублировать и внутре и снаружи.

если не умеешь - то наверное да :)
папку с файлами впихнуть в докер можно его стандартными средствами.
выдернуть из докера папку из нутре докера для пользования снаружи потребует весьма нехитрых изгибательств…
KISS !!

Ну я не спец в плюсах и сложностях эксплуатации и разработки но выглядит что у вас глобально не верный подход.

Если у меня есть тулчейн который что то делает (для сборки проекта и т.п.) мне не нужен доступ к его исходникам в рамках работы с проектом. Тут все может лежать в докере и крутиться и прекрасно работать - чему я как разработчик буду рад.

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

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

Вариантов у вас два:

• ваша идее очень умная и можно настроить мапинг прямо внутрь контейнера
• просто взять предусмотреть тривиальную команду «распаковки» нужных файлов из имеджа на фс для целей разработки

Ты выбрал путь которым пойдешь?)

%тс% я так понимаю «стандартные инклуды» нужны снаружи.

Ты неправильно понимаешь. Снаружи TCу нужен только его git-проект с его исходниками, который монтируется в контейнере. Всё остальное лежит непосредственно в контейнере, поскольку является составной частью соответствующих пакетов dev-среды, установленых при создании docker-образа.

Честно говоря, удивлен что многие еще так и не добрались до процесса разработки с использованием контейнеров. Это реально очень удобно, поскольку вы разрабатываете и отлаживаете код на своем локальном компе в среде, гарантированно совместимой с production. Причем, эта самая среда на своем компе может свободно меняться в зависимости от конкретного проекта.

теоритически да :) но практике в ide надо посмотреть "include «такая/зависимость.h», и ни файл не найден, ни объявления внутри.
%тс% хидеры нужны снаружи :)

%тс% хидеры нужны снаружи :)

Нет, его IDE умеет работать с контейнерами.

теоритически да :) но практике …

Ты не понимаешь, как работает VSCode с контейнерами. Почитай:

https://code.visualstudio.com/docs/devcontainers/containers

Компиляция, навигация по исходникам (в том числе по h-файлам), поддержа Git и прочее - всё это выполняется в среде контейнера. Там же, в среде контейнера, устанавливаются и все необходимые расширения VSCode.

Так может проще и IDE в докер засунуть, раз пошла такая пьянка?

Практиковал и такой вариант причём контейнер был arm-овский, там QtCreator собранный под arm с прозрачной user-mode эмуляцией на движке qemu прозрачно интегрированной в докер.

Но тогда образ очень распухает, среда хуже интегрируется с окружением, и главное - приходится библиотеки выбирать так чтоб не было конфликтов между IDE и разраатываемого ПО.

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

Раз пути нет, засунь туда и свою IDE, целиком :D А чё в докер нельзя сделать что-то типа mount --bind lalala lululu? У меня в chroot натыкана куча dev пакетов и всякие NDK валяются, я туда просто монтирую каталог исходников и всё и chroot каталог make хотя я не так, а вот так делаю firejail --chroot=./debian_stable ls но сути это не меняет, код правлю у себя, а собирается он уже внутрях. И всё, всё прозрачно, только удаляя чрут надо не забывать отмонтировать, а то это, кирдык :D . Наверное у тебя тоже так можно.

Хотя даже так я делаю редко. Хз

Во

• https://docs.docker.com/storage/bind-mounts/

Смонтируй в него просто исходники и всё, правишь на хосте, собираешь в песочнице.

Попробовал dev-containers через SSH плагин. Оказалось, что в докере такой старый libc, что он не поддерживается dev-containers. Во всяком случае, вскод ругается, что ОС не поддерживается при подключении к докеру.

С другой стороны, как-то оно всё же подключилось, потому что вскодовская консоль кажет именно докеровскую ФС. И вроде даже навигация по коду как-то работает.

И вроде даже навигация по коду как-то работает.

Но на самом деле нет. Вот так всегда: моднейшие свистоперделки и гуд практисес - не в этом проекте.

motherfucker, do you speak it?

Пофиксил за тебя