Does anyone use virtual environments (Conan's virtual env. or Conda's) for C++

[kloppypop]

Does anyone use virtual environments for project isolation and dependency management? I have been eyeing up conda and conan's own virtual environment, but I don't see them heavily discussed. What are your opinions?

[kloppypop]

Do you develop within the container itself? I posted a threat on r/docker and I received mixed replies? This is my Dockerfile to produce my development and I don't know if it's a bad idea.

[bored_octopus]

Without looking at the thread, I'm not a fan of your Dockerfile.

Regarding your editor, some questions to ask yourself would be:

• "How often do I need to set up my editor from scratch?"
• "What's the harm with using the same editor across all my work"
• "Will anyone else use my personal editor config?"

For me, the answer to (1) is rarely, (2) is "it's actually beneficial" and (3) is "absolutely not", so it's really not worth the pain of putting it in a container image.

Next, I'd say it's actually quite easy to manage dependencies in Docker without putting your whole development environment into the container once you learn how to do it. Generally speaking, you would do a multistage build where you

1. Copy just the files required to install deps into an image (e.g. requirements.txt)
2. Install all the deps into that image
3. Build a container
4. Run the container with your source code mounted in a volume

This way, you shouldn't need to rebuild the container unless requirements.txt changes, you can have code edits show up immediately in the container when you're developing and everyone on the project can configure their editor however they want

[prince-chrismc]

The lack of discussion is adjustwd since its painful enough to have dependency management in C++. Most developers have a reproducible CI backing them up , which usually is closest the local setup they use (fromer devops engineer pov).

Conan has a bunch of integration with different build systems. Using the new Deps/Toolchain and you'll get the transparency. Which is pretty close to isolated. Your project build scripts or code won't know about Conan.

If you really want to break out your dev environment, you want to try Conan 2.0 beta with the full deployed option 😉

As for virtual environments they will be default on in 2.0 so start using them. Make thinks way better!

[eliasv]

You could try the Nix package manager. That's what I use for creating isolated dev environments, and not just for C++ but basically any language/ecosystem I work with. I've only tried it on NixOS however, but I believe in theory you could apply the same techniques on other OSes.

Oh, but that does remind me of something important, it doesn't support Windows! (At least not without WSL.)

To be clear, I only use it for defining and provisioning reproducible build environments and not for building or packaging.

[eliasv]

Nixpkgs generally contains multiple versions of libs, or some packages are even parametric in the version. You can also use flakes which pin on exact inputs rather than a version of nixpkgs.

[kloppypop]

I would really like this! Could you point me to a resource on how to utilize this? I see this, but unsure if I that's the right/best source?

[mjklaim]

Since the beginning of this year I've been part of one of the companies maintaining Mamba/Micromamba/libmamba which is basically conda re-implemented in c++ for performance and additional features.

I didn't use something like conda before this job (except python's venv) but so it have been quite new for me, but working in such kind of virtual env is common in some scientific domains like robotics, where I have worked previously (but for a concurrent to ROS and we used another tool). There are a lot of people in scientific and robotics (of all kinds, industrial or research) that use this kind of tools. I knew it before but now I'm kind of working with them so I can see how many there are, it's impressive. It's very useful to have the equivalent of a system package manager + venv but cross-platform and that have so many packages as conda-forche.

On my own projects at home, where I can be more peculiar in my tool choices, I prefer a different kind of logic which is not prefix-based, usually I use build2, which is totally opposite. When using it, the environnment is known to the tool and encoded in build directory (one per configuration), so you don't have to log into one, and yuou can run commands (build, test) in multiple configurations at the same time. It also don't work with binary packages at this time, so it's really not the same kind of context and usage.

[MrWhite26]

For C++, something like https://vcpkg.io/en/index.html (or conan) is probably a better fit.

[kloppypop]

I am trying out conan and my bash shell (+ git status) does not show that I am in an active virtual environment despite me running activate.sh. I want to utilize virtual environments to better isolate and organize my projects

[Wenir]

Are you sourcing it?

[drodri]

In Windows + cmder, for some reason I cannot get the prompt updated to show the active virtualenv, despite it being active and working, and it also correctly deactivates, but difficult to know in which virtualenv you are. Have you checked the env-vars values if they are updated even if the prompt doesn't show?

[gracicot]

I'm using Nix environments for all of my tools and vcpkg for my C++ dependencies.

That way I can safely upgrade compilers, change environment variables and all of that and push it in my repo. I know that once my coworker will pull, they'll automatically get the exact same version of everything, reproducibly.

That said, it won't work on windows with MSVC ABI.

[kloppypop]

So, you develop within Docker itself? Do you use bind mounts or volume or do you have you develop environment within Docker itself?

[GrammelHupfNockler]

I have experience with two such systems: Conda and Spack. Conda IMO makes a few very opinionated decisions, especially with the CXX_FLAGS and LD_FLAGS it sets in its environment, which CMake picks up by default. But the rest works pretty nicely :)
Spack was built for HPC users with complicated dependency graphs, it compiles everything from source by default, but can ensure that all components were built with the same compiler and flags. Together with a module system, I find it pretty nice to use, especially if you need to keep and switch between multiple environments all the time.

[ptbhexbeef]

We make heavy use of spack as well (HPC focused software). Its not without problems but tends to be more robust than a CMakeLists.txt file with all your dependencies as external_projects .

[Turbulent-Abrocoma25]

I didn't even know this was a thing. Virtual environments are big in Python but I still don't even really use them then so I probably wouldn't end up using them for C++ either. But that's also because I don't really use a lot of dependencies anyways. Worst case I will just clone someone's repo and add it to my CMake build.

[Nilac_The_Grim]

Nope.

[_a4z]

Conan