The local docker client will not be recognized by P圜harm otherwise. In the Docker settings it is important to enable the “Expose daemon on tcp://localhost:2375 without TLS” option in the general settings. Configuration Docker Client Configuration Setup requirements other than P圜harm Professional is only a working Docker Client (in this example on a Windows machine). Using the WSL remote interpreter is a descent choice for developing with a Windows PC in Linux based environment (e.g.
The SSH remote interpreter is also extremely useful in the cloud context, for example if you want to develop Spark code on a remote cluster (EMR in AWS). It is worth mentioning that not only Docker can be used as a remote interpreter but also Virtual Environments (P圜harm Community Edition), WSL ( VSCode and P圜harm Professional) and SSH ( VSCode and P圜harm Professional). One other IDE that provides similar options is VSCode and there are probably many more. Next to P圜harm there are also other IDEs that provide such a functionality. The main reason for this choice is that P圜harm Professional provides a very easy and understandable interface for using Docker as a remote interpreter.
In this post we will have a look on how to develop containerized Python code with P圜harm Professional. Luckily this is something the developers of many IDEs also realized and they recently started to provide options to use remote interpreters that run e.g. This is still it is a bit messy, as we need to start our scripts from the command line and we have no possibility to use the strong features of our IDE such as debugging. That way we can immediately run our changes and see the result.
To move even faster we have come up with the idea to mount our working directory into our container and install local packages in interactive mode (as we are talking about Python „pip install -e“ will do the job).
This is already much faster but still not fast enough, as we need to rebuild the container after every change. To speed things up and be able to dig inside specific behavior, it would be nice to mimic the productive environment in a local setup as close as possible.Īs all this services are based on containers, we might come up with the idea to build and run our corresponding Docker images locally. Also, debugging becomes quite a hard job if you cannot set any breakpoints to look into the current state of more complex scripts or even own packages. The problem with this services is that we have long development and debug cycles as we often need to redeploy our whole setup to see the effect of our changes.