conan-clion-plugin
conan-clion-plugin copied to clipboard
conan-io
Run programs in Conan virtualenv
Given I have a runnable program in CLion I want to be able to run it in a Conan virtualenv So that DLLs in packages that it depends on can be found.
I'm copy-pasting a conversation I had on the JetBrains slack with clues for how this can be done:
Is it possible for a plugin to add environment variables to run configurations in CLion?
Yes, you can use platform API com.intellij.execution.configuration.RunConfigurationExtensionBase that allows patching command line of any run configuration. For CLion specific run configuration you can use com.jetbrains.cidr.execution.CidrRunConfigurationExtensionBase
Just extend patchCommandLine and use GeneralCommandLine#withEnvironment() to change environment that is used to run configuration. It should work
The withEnvironment method mentioned above has the following signature:
public GeneralCommandLine withEnvironment(@Nullable Map<String, String> environment)
I'm opening an issue in the Conan repo to add a tool that can help us do this in a platform-independent way.
As far as the UX of this feature, I'm imagining the user having a list of the run configurations in a settings tab, and they can check a box "run in virtualenv" for each.
There is a lot of interest around this issue or something very close to it, and we need to gather all this feedback and come up with a solution suitable for all these slightly different use-cases. Here it is the same problem: need a virtualenv to run the IDE (build, run, debug), and envision a solution through the IDE plugins.
About the environment, would it be better to just inject the environment always? Every time the user runs a command (build, debug, run), inject Conan variables according to the selected CMake profile. It would work here and also for the VS plugin.
It seems like a reasonable default, but of course you should have an opt-out, it should not be too hard to implement that.
There are some caveats to this simple solution, and this goes for my proposed solution to #33 as well.
Setting the environment variables from conan for every build/debug/run assumes that every single CMake target actually wants the Conan dependencies in the environment.
Obviously, this is not always the case, and there are CMake targets that users might specify that shouldn't have the Conan environment- in fact, doing so might cause subtle bugs where one shared library the target links to happens to have a different version that is in the Conan environment.
Unlikely, but possible.
Furthermore, if such a target was a dependency of another target that does need the Conan environment when building, the whole thing breaks down because both are being built with the same CMake invocation with conflicting environment needs.
That being said, I think this is a good way forward that will work in the vast majority of cases.
I think that we can consider these scenarios as the symptom of something wrong in the project: the same dependency with different versions. Although I agree with you and that is something that could happen, if the solution of adding conan environment always works for the vast majority of cases (now it is broken, DLLs are not found for the 100%) then I think it is the way to go and we'll deal with the exceptions in the future.
We really need end-to-end tests to be sure that we are fixing some issues and not breaking other use-cases.
I'm moving this to the next release, there would be some ideas from https://github.com/conan-io/conan/issues/5737#issuecomment-531464389 that could be applied to this scenario: use always the virtualenv generator (it will generate the script but also an easy to parse file with all the environment) and apply environment to plugin calls.
Here it is the issue refactoring virtualenvs in Conan, it should provide a file with the environment variables: https://github.com/conan-io/conan/issues/5821
Next Conan release, v1.21, to be released soon will include the .env files https://github.com/conan-io/conan/pull/5989 We can use those files (if not the activate/deactivate scripts) to create the sandbox for the CLion commands: populate a dictionary with the expected environment and use it together with the command.
Some notes: There's a plugin here: https://github.com/ashald/EnvFile which adds env vars from a .env file... not dissimilar to what we're doing, so it should work as a good reference for how it can be done.
They add a tab to the run configuration UI to add a .env file. Maybe we could do a similar thing but with a simple checkbox "run in Conan virtualenv".