Recommend docker as the default for vscode/devcontainers

I switched to docker a while back so I haven't had a chance to run through a clean install lately but here's some feedback:
https://universal-blue.discourse.group/t/should-we-really-recommend-vscode-podman-as-supported/220
Maybe we should just do docker ootb? Currently we just docker to turn that on but maybe we should consider it having it on ootb as well, thoughts?

+1 for Docker enabled by default.  Just makes everything so much easier, and we could create one of your fancy charm just entries to switch the systemd unit to disabled

+1 for Docker enabled by default.  Just makes everything so much easier, and we could create one of your fancy charm just entries to switch the systemd unit to disabled

Sounds good to me, we can have it on by default and have just docker be like a just devmode toggle.
What do we do about this thing?
https://github.com/ublue-os/bluefin/blob/main/dx/usr/etc/skel.d/.config/Code/User/settings.json

Does docker not use selinux labels, i ahvent used docker on fedora cause i dont need it but based on what i know --security-opts=labels=disabled flag would still be needed besides shipping basic settings cor dev cintainers should be enough same with installing dev containers extension, been a while since i setup devcontainers since i have settings sync in vscode

Sounds good to me, we can have it on by default and have just docker be like a just devmode toggle.
What do we do about this thing?
https://github.com/ublue-os/bluefin/blob/main/dx/usr/etc/skel.d/.config/Code/User/settings.json

Parts of this would need to be removed as it is setup for podman not docker

Does docker not use selinux labels, i ahvent used docker on fedora cause i dont need it but based on what i know --security-opts=labels=disabled flag would still be needed besides shipping basic settings cor dev cintainers should be enough same with installing dev containers extension, been a while since i setup devcontainers since i have settings sync in vscode
But i also use devcontainers as a way to start container and dont use more advanced features of devcontainers

It does not seem to be the case.
I did enable docker here, removed all my 'extra' flags... Everything just works(tm). All vs code commands, generated files, simple, etc... All out of the box without "special" arguments

Strange cause everything im seeing it should be the case but im not gonna go and test it cause i dont want to run it, cause yea im not into setting up docker-rootless since i didnt have much luck with it in past and i dont want to run my cintainer engine as root

I believe podman is still a valid use case, but maybe not to be default as it demands some effort to work.
I would ratter run only podman, but I also use testcontainers a lot, and it also does not like podman.. so I have to run docker anyway :/ ...
Is there an "extra documentation" location? I would be nice to have the documentation in place for people that prefer podman to docker, without having to "fish" through several github issues

Yeah we could document it on discourse with the 'documentation' tag for people who want it.

Strongly agree with docker enabled by default for dx.
Especially with the dev-container use case, docker works much better than using old extensions and needing to switch configurations over to podman.
I still predominantly use podman except when interacting with dev-containers. Distrobox for dev-containers is painful compared to just using Devpod or your own .devcontainer.json. And those work much better with docker than podman.

I know I'm the minority here but I prefer Podman. If Docker gets flipped to default can users still have the option to continue using rootless Podman for everything? Bluefin has the best OOTB rootless Podman setup I've seen, since there's nothing to configure. On most systems, you have to configure this thing and that thing before it's ready to go.

We don't really modify the upstream fedora podman experience so I think you should be good. I think it's just a matter of making sure vscode does the right thing depending on which one the user is using? Does anyone wanna take a stab at enabling this so we can see what it'll look like and play with it?

We should also probably look at Dan's recommendations: https://universal-blue.discourse.group/t/should-we-really-recommend-vscode-podman-as-supported/220/9

I ll give it a try on my machine

It does not seem to fix the compatibility problem with vscode and devcontainers. I added my findings here:
https://universal-blue.discourse.group/t/should-we-really-recommend-vscode-podman-as-supported/220/10

Ok I've PRed in turning the docker socket by default, I need someone to tell me where the best place to add a user to the docker group is, and then I need to know where I should put the snippet for preinstalling the remote containers extension, that should get us working docker-ootb without extra steps.
And I think we need to still fix it so when you go in the terminal it's your user and not root?

And I think we need to still fix it so when you go in the terminal it's your user and not root?

For me, it is using the proper user inside the devcontainer, not root. So, I don't think this is necessary

I tried a fresh VM last night, when connecting the stock distrobox to vscode it's still root. But I didn't test a devcontainer (I should have!).

Aw, I see. I did test only devcontainers  with vscode

For a distrobox style container you have to set up configurations in vscode to not connect as root.
With your distrobox, edit the attached-container named config. You can use vscodes environment variables to grab the username.
Docker by default would be for dev-containers and not distrobox. Also seems to be mixing and matching podman/docker since I thought we were still using podman for distroboxes.

I believe it's not possible to have both podman and docker running inside vscode as container engine.

Docker by default would be for dev-containers and not distrobox.

Mind taking a look here?
https://github.com/ublue-os/bluefin/pull/745

Yeah. I'm using docker with Devpod which does an ssh connection.
For working with distroboxes I've been doing a similar thing and having an init system so I can ssh into them from vscode even with podman backend. Basically, if I have a container that I know will be more of a pet (takes a long time to build/configure).

We're shooting for devcontainers-first as the default, but I am unsure on the changes we need to make to get what your setup looks like ootb.
So looks like we can just keep the extension installation and the config but not the distrobox-shim part?

My setup right now is default vs-code remote deontainer. No additional configurations set for containers.
By default remote dev-container uses docker. All features should work out of the box so long as the docker socket is present and the user is a member of the docker group. To me this gives the experience I would expect and most matches vscode on other platforms.
Devpod can use the devcontainer.json specification as well, and when set to use docker can use all of the features as well. This connects via ssh instead so avoids the remote-devcontainer extension. I believe it will auto-install the remote-ssh extension if it isn't installed already.
If a person wants to use a distrobox they have to work around the fact that the extension wants to connect to root by default. The shim method in that PR is from the distrobox faq. I believe that would break using the extension normally and require you to use a distrobox-style container instead. If you want to use a distrobox with vscode, you either need to drop the appropriate configuration in:
~/.config/Code/User/globalStorage/ms-vscode-remote.remote-containers/nameConfigs/name-of-container.json

With something at a minimum (distrobox-host-exec needs an environment variable setting the name of the container to work and that should be set on the specific container config which is different that this config):
{
    "remoteUser": "${localEnv:USER}"
}

And it has to have the same container manager as the distrobox. You will also want to set up a custom terminal profile to have a proper distrobox terminal.
Since doing all of that is a pain. I instead just have a distrobox with the --init flag set and systemd installed. I have SSH running. Change the port to something random and high. Then just use the remote-ssh extension to access it. Since I pretty much only want to connect to a distrobox in vscode if it's more of a pet (ml). This seems like a decent balance. Since it's using the remote-ssh extension I don't have to worry about docker vs podman in vscode/distrobox. Which in turn kinda matches what devpod is doing since working with the dev-containers extension directly isn't actually that nice.

OK just spent some time in a clean VM. (Wow F39 is looking good with the latest logomenu and prompt terminal!)

To me this gives the experience I would expect and most matches vscode on other platforms.

Agree 100%, let's just match what the others do. To do this I had to do the following (and this is what I think we should do):

Remove the podman references from this file: https://github.com/ublue-os/bluefin/blob/main/dx/usr/etc/skel.d/.config/Code/User/settings.json
Run code --install-extension ms-vscode-remote.remote-containers on first login on the dx image only
Add the user to the docker group, preferably in an existing step somewhere so the user doesn't need to reboot/logout for it to take effect. The newgrp thing didn't work for me in the VM.

And then we document the 2 lines needed to use podman for people who want to do that. Everyone else will just get the same vscode/docker experience as their macs. Then we'll be done.
And then distrobox/toolbox integration with code is all up to the user if they want, then we'll fix up the docs to make it more clear that the default experience is devcontainers. Then we can go on holiday!
Opinions?

I agree.
I think we take the pull request items and put it into the discourse as a way to wire up your distrobox/toolbox.
For the people that want to go that route, just having the steps laid out should be good. It's not the default way to interact with dev-containers.
I'm okay with the user not being added to docker group by default. It has a security implication. If we make assumptions we can add the user. Probably a sane assumption is that members of the wheel group should be part of docker group.

Would it maybe make sense to enable --init for the default ubuntu/fedora distrobox that is created (in podman, I believe) on bluefin, to make them accessible to vscode ?

I would still probably say no.
You need to change the ssh port to a non privileged port. You'll also would want to turn off strict host checking for that one entry and now we are messing with the users ssh config. I think a tutorial/page on ways to connect to a distrobox would be sufficient. Have it just be discoverable in documentation.

Updated the docs, users will need to explicitly opt into the group addition via just dx-group, though we should have called it devmode-groups or something to match, but whatever we can fix that later:
https://universal-blue.discourse.group/docs?topic=39


Support for new solc-js ^0.5.4 for JavaTron 3.6

This supports the new tron solidity compiler for ^0.5.4, usable with the upcoming JavaTron 3.6.
It requires that the pragma in the contract is compatible.
For example, compiling a contract with
pragma solidity ^0.4.23;

will fail. A correct approach is to change it to
pragma solidity >=0.4.23 <0.6.0;

Alternatively, in tronbox.js, you can add the optionuseZeroFourCompiler: true to force TronBox to compile the contract as if the connected full node hosts a version of JavaTron less then 3.6.
This PR also solves a vulnerability issue due to (unused) web3 0.20.7.

When I compile the contract I still get this in the compiled contract:
  "compiler": {
    "name": "solc",
    "version": "0.4.25+commit.69a1e720.Emscripten.clang"
  },


bump ruff to 0.8.1

Fix for https://github.com/DefectDojo/django-DefectDojo/pull/11349

Sorry for the delay, this should be fine now @mtesauro and @Maffooch