this post was submitted on 06 Mar 2024
16 points (100.0% liked)

Programming

22372 readers
53 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
 

So I am not a professional programmer, but I do like to tinker with projects and just teach myself stuff (in python and now rust). I currently just install stuff on my linux distro off of the repos or anaconda for python. I've never had any particular issue or anything. I was thinking about maybe moving projects into a container just so that they are more cleanly separated from my base install. I am mostly wondering about how the community uses containers and when they are most appropriate and when they are more issue than they are worth. I think it will be good for learning, but want to hear from people who do it for a living.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 7 points 1 year ago (5 children)

Containers are used for a whole bunch of reasons. I'll address just one: process isolation. I'll only do one because I've ran into times when containers were not helpful. And it may lead to some funny stories and interesting discussion from others!

A rule of thumb for me is that if the process is well-behaved, has its dependencies under control and doesn't keep uneccesary state, then it may not need the isolation provided by a container and all the tooling that comes with it.

On one extreme, should we run ls in a container? Probably not. It doesn't write to the filesystem and has only a handful of dependencies available on pretty much any Unix-like/Linux system.

But on the other extreme, what about that big bad internal Node.JS application which requires some weird outdated Python dependencies that has many hardcoded paths and package versions? The original developer is long gone. It dumps all sorts of shit to the filesystem. Nobody is really sure whether those files are used as a cache or they contain some critical state management. Who wants to spend the time and money to tidy that thing up? In this scenario containers can be used to hermetically seal a fragile thing. This can come back to bite you. Instead of actually improving the software to be portable and robust enough to work in varied execution environments (different operating systems, on a laptop, as a library...), you kick the can down the road.

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago) (2 children)

And FYI to OP, if you can't install two versions of the same library at the same time (ex: numpy 1.25 and numpy 1.19) then the answer to "has its dependencies under control?" is generally "no".

  • Deno (successor to NodeJS) is "yes" by default, and has very very few exceptions
  • Rust can by default, and has few but notable/relevant exceptions
  • Python (without venv) cannot (even with venv, each project can be different, but 1 project still can't reliably have two versions of numpy)
  • NodeJS can, but it was kind of an afterthought, and it has tons modules that are notable exceptions
[–] [email protected] 2 points 1 year ago (1 children)

I have not gotten to the point where I would want two versions of the same library, but that is good to know.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Sadly it still causes system instability even if you NEVER need the feature.

You might not need numpy at all, but Pandas needs numpy and Opencv needs numpy. Sometimes pandas needs one version and Opencv needs a different version. Well... python only allows one global verison of numpy, so pandas and opencv fight over which one they want installed, and the looser is forced to use a numpy they were not designed/tested for. Upgrading pandas might also upgrade numpy and break opencv. That causes system instability.

Stable systems like cargo coupld upgrade pandas, have pandas use numpy 1.29 without touching/breaking opencv (opencv would still importing/using using numpy 1.19 or whatever). That stability is only possible if the system is capable of having two versions of the same dependency at the same time.

load more comments (2 replies)