CLI v0.13.0 has been released - support for Python virtual environments instead of Docker 🎉

CLI v0.13.0 has been released :tada:

A new version of the CLI has been released. This release includes:

  • A completely new way to develop apps using a Python virtual environment as isolation mode instead of Docker
  • A warning when you publish an app and the supplied tag differs from the Git tag (you need to have this tag checked out). You can choose to continue the publishing process or not.
  • Small addition to the check-system command

You can upgrade your CLI with the following command:

viktor-cli upgrade

The past months we have been working hard to enable development on the VIKTOR platform using a Python virtual environment instead of Docker. This means that Docker is no longer a hard requirement to use VIKTOR and you can develop apps purely on Windows. We think that this will make it a lot easier for (first-time) users to start and get to a running app. If you want to use a virtual environment as isolation mode instead of Docker you can use the following command to (re)configure the CLI:

viktor-cli configure

and subsequently install the app in the virtual environment:

viktor-cli install

you can start the app just as before:

viktor-cli start

Please keep in mind that there are several differences between using Docker and a Python virtual environment. One difference to note is that with a virtual environment the CLI uses the Python version that is installed on your system (with docker this was pinned to 3.7). If you have ‘older’ versions of dependencies defined in requirements.txt this might mean that no wheels are available for ‘new’ Python versions. In that case the dependency needs to be built from source which can lead to installation errors due to missing build dependencies. Updating to a newer version of the depedency in many cases solves the problem. Other differences can be found in the troubleshooting section of the installation instructions.


Thanks for explanation. I use Ubuntu 20.04 - WSL to run the apps. If i configure the venv and try to install the application it says:

Creating virtual environment
Exiting because of an error: exec: "python": executable file not found in $PATH

Which might be because it should be python3 for Linux.

If I run ./viktor-cli start nothing seems to happen either.

Any idea how to handle this transformation on a WSL on Windows?

Hi Johan,

Thanks for the message. We will address this in an update of the CLI. For now you can alias python3 with python.

Add the following line to ~/.bash_aliases:

alias python="python3"

Make sure that the follwoing lines are uncommented in ~/.bashrc:

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases

Next either restart your terminal or source the ~/.bashrc file:

source ~/.bashrc

Maybe good to note; if you use a virtual environment instead of docker you do not necessarily need to be on WSL2. With this setting you can use VIKTOR on Windows without docker.

Update 13:30
@Johan_Tuls My apologies I was a bit too quick with my reply. The above solution works for your bash terminal, however, the CLI starts a python process instead of running the command via the terminal. You can do the following:

sudo apt-get install python-is-python3
sudo apt-get install python3.8-venv

Update the last command with your python version

After this viktor-cli install should work

Another Johan here with the same problem (I hope it is not in the name) :wink:
I also tried to move away from Docker, and get exactly the same error, but then in Visual Studio on
Windows 10.
Though, the solution isn’t really clear but that could be windows/linux related. Any help on windows?

Hi Johan,

Do you have a Python installation on Windows? With Docker this wasn’t strictly necessary as we used a docker image that had a pre-installed version of Python. Now that you move away from Docker a Python installation on your OS becomes a hard requirement. You can check if Python is installed and added to the PATH variable by typing python --version in your terminal.

If this command returns an error and you have Python installed, please check if the path to the Python installation is added to the PATH variable. You can do this by typing ‘Edit the system environment variables’ in the search bar. After that click the button ‘Environment Variables…’ and select ‘Path’ by double-clicking. If the path to the Python installation is not present add it with the ‘New’ button. Please note that you should add the main directory and the scripts directory, for example:

C:\Users\[your username here]\AppData\Local\Programs\Python\Python39\
C:\Users\[your username here]\AppData\Local\Programs\Python\Python39\Scripts\

If your Python installation is located in another directory the paths should be updated accordingly

I keep being unable to get it to work. I have python installed so it had to be something with the ‘system variables’, I chose C:\Program Files\Python37_64 as the folder.
So added it to the system variables (to both the user variables and system variables, since it didn’t work)
I first tried the %PROGRAM FILES%\Python… and then the ‘regular’ path.

When that didn’t resolve the error, I checked the interpeter in PyCharm, that one was showing an error, so added adding the path and then the error was gone.
Now the funny part (that I don’t get), python --version still returned an error. Then I just tried installing again, and that DID work! So error is resolved but I don’t get why. Hope this helps for other people having similar issues.

Hi @Johan,

The environment variables you added point to the Python installation of your system. After adding these variables you should be able to run python --version in Powershell or your Command Prompt and get the version.

The screenshot you show of Pycharm shows a Python interpreter inside a virtual environment. This virtual environment folder is created by the CLI during installation. If a virtual environment folder is already present the CLI deletes is and creates a new one. My guess is that this action solved the problem

We have just released a patch for the CLI to address the problem @Johan_Tuls encountered. Download this patch with

viktor-cli upgrade