0

As far as I understand, Gitpod creates a pod which runs a Linux server container that includes my pre-configured IDE.
I am not too familiar with pods and containers, so please correct me if I'm wrong.

To my understanding, a container is essentially a VM, or are there any differences between the two?

Now, moving on to Python, which I am also just getting to know.
So a common practice is to set up a virtual environment, so that packages will be installed in there, and not globally, on the computer running the project.

Note - I will be abbreviating with "venv", but I will not be specifically referring to venv/virtualenv/etc.

Comparing it to NodeJS with which I am more familiar, that would be the same as using project/.node_modules vs usr/local/lib/.node_modules
By default npm i installs on the repository, and only installs on the machine when using the -g option.
Is that correct so far?*

So, with that information in mind, since Gitpod is running a container specifically built to serve as a single project IDE - Do I even need to run a venv?

  • I can see a use case in which I may be testing how my code runs against Python3 and Python2.8, thus using two different venvs
    (I now wonder how that would look code-wise, how would the scripts import the correct libraries, but that question is way off-topic )

Anyway, my question assumes:

  • If I were to use it on a local machine, I'd only need one venv
  • In terms of Python version and package collisions:
    • Either the default Gitpod image satisfies my needs
    • Or, well, I can edit the image myself anyway

* Footnote - I apologise for asking many questions beside the main one.
I hope it is not against the rules, I simply want to know if I understand correctly

Dean Ayalon
  • 7
  • 7

1 Answers1

1

In an attempt to answer this objectively, I think the shortest argument for using both boils down to:

  1. The Gitpod provides your development environment: editors, IDEs, Python installations that a virtual environment can use, etc.

  2. The virtual environment provides your application's execution environment: the exact Python version and packages it needs to run.

Your preferred tooling and workflow, however, might make this distinction moot.

chepner
  • 497,756
  • 71
  • 530
  • 681
  • I see, I did guess that might have something to do with separating the work environment packages with the project packages, just I don't see how it might misbehave or why I'd need colliding packages on my development environment. Thank you :) – Dean Ayalon Jul 07 '22 at 15:51
  • 1
    You mentioned testing. For your *developement* pod, you might have Python 3.8, Python 3.9, Python 3.10, and (as of today) a dev version of Python 3.11 installed. You might have a separate venv to run and test your code for each of those 4 version, because different Python versions might need different versions of your packages. In a *production* pod, of course, you'll only need one version of Python, and the virtual env wouldn't be necessary (as there's nothing to collide with). – chepner Jul 07 '22 at 15:56
  • That last addition was great, thank you!! – Dean Ayalon Jul 07 '22 at 16:35