Skip to content

Add documentation for development environment configuration #2153

Open

Description

Problem

The documentation that exists only describes the bare minimum for a working development environment. It does not cover the steps required for setting up, e.g., a Python development environment that works with jedi or pylance to get auto-complete suggestions in editors such as Vim or VSCode.

Description

There are two options for configuring this. Both have trade-offs as far as ease of use goes:

  1. Use the Python interpreter inside the docker container. This can take two forms. Either you can use something like https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers or IntelliJ's own version which is built in. Or you can mount the Python installation from the container to the local machine and point your editor to that executable. The latter only works if the Python executable in the container will run on your local machine (i.e., you run Linux and happen to have a similar enough execution environment to the Python base image). You could use a local interpreter but mount the lib directory into the virtual environment to avoid needing to download dependencies twice (in the second option below), but it's bound to be flaky. The first option is almost certainly the most reliable, but requires proprietary editors/editor extensions and is therefore not free. It is probably the "easiest" though, especially for VSCode users if we supplied a devcontainers.json file in our monorepo. PyCharm/IntelliJ may have a similar auto-configuration tool. This option would not work for vim users, as far as I can tell, as Jedi doesn't support remote interpreters.
  2. Run pipenv install --dev inside each project directory and configure your editor to use the appropriate interpreter depending on the directory you're working in. This can be done in VSCode (both free and non-free versions) using multi-directory workspaces. I'm sure PyCharm/IntelliJ and vim-jedi have similar capabilities. This is almost certainly the most reliable option, but it does duplicate dependency installation (once on the local and once more inside the container).

Either way, one of these is required to get completions working locally. My preference is the second because it doesn't require any special tools aside from the ones we already require. However, it does warrant some special documentation. For example, the API depends on psycopg2, which requires pg_config to exist locally. On macOS and Linux you'll need to install something like Arch's postgresql-libs package or just install Postgres in its entirety (it is usually distributed with the userland libraries).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    • Status

      📋 Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions