3 ms·

I'm surprised there's no mention of Docker or other container-based strategies. In my world, Docker has neatly, cleanly and -- perhaps most importantly -- _port

I'm surprised there's no mention of Docker or other container-based strategies. In my world, Docker has neatly, cleanly and -- perhaps most importantly -- _portably_ addressed all of the "environment management" and "Python version management" concerns outlined in this post.

fbdab103 3y ago
As much as I hate to admit it, it does seem the most straight-forward option to recommend. Even after all of these years of this being an obvious problem. Which reminds me that I need to revisit devcontainers for my work. When I first tried them, I ran into a few rough edges which might have since been resolved.
smitty1e 3y ago
The Venn in The Famous Article shows five overlapping dimensions of concern, and a fistful of tools capturing various overlaps thereof.
GorsyGentle 3y ago
In a way I'm glad it's not mentioned. As a FreeBSD user, nothing is more disheartening than to find a cool and interesting project written in a great^1 language without any packaging or distribution method other than "here's my container bruh". Like, ughh. ^1 Caveat, making a package of a Python project can be a rabbit hole can be a real pita. Virtual envs are usually good enough for most stuff until I start to need a compiler in every jail. Nowadays I'm looking almost only at Go (best) or Rust because their distribution is trivial in comparison.
- ethagnawl 3y ago
  I'm with you on pretty much all of what you've said. The _trivial distribution story_ is part of the reason I handed off maintenance of tmuxinator and started working on rmuxinator (spiritual successor written in Rust). Otherwise, I often find myself needing to deploy Python/Node/Ruby at $WORK and I'd really rather not try to get a bunch of dev/prod machines (possibly running different OSes!) trying to use whatever the flavor of the day for managing virtual environments, interpreter versions, packages, etc. is.
m463 3y ago
I would imagine that is a superset of all the others. I've spent waaay to much time trying to docker build a python container with various combinations of apt-get/pacman/apk + pip/conda/venv
- ethagnawl 3y ago
  You're right that it's not trivial if you're starting from scratch but, in theory, you only need to get it right once. Even if you did need to move to a different strategy in the future because pip stopped being included in your container's distro or something, that's a single point of failure and not something that needs to be sorted out on every dev/prod machine. To move up a level of abstraction, though, the official Python image pretty much does The Right Thing by default (copy requirements.txt, pip install, execute some command, etc.). Of course that isn't going to work for every scenario but it's a good place to start.
Brian_K_White 3y ago
A container is a shit way to package something. It's not a solution it's a response. It's "This thing makes no attempt to be portable or coordinate with the rest of the world, so the only way to package it is to include a copy of it's own entire world." There is no excuse for a python script to be a hothouse flower. It's one thing to choose to containerize something for your own operational reasons, but something else entirely for something to be so fragile that thst's the only way it even works is just you need a copy of the devs laptop. It's garbage.

fbdab103 3y ago

As much as I hate to admit it, it does seem the most straight-forward option to recommend. Even after all of these years of this being an obvious problem. Which reminds me that I need to revisit devcontainers for my work. When I first tried them, I ran into a few rough edges which might have since been resolved.

smitty1e 3y ago

The Venn in The Famous Article shows five overlapping dimensions of concern, and a fistful of tools capturing various overlaps thereof.

GorsyGentle 3y ago

In a way I'm glad it's not mentioned. As a FreeBSD user, nothing is more disheartening than to find a cool and interesting project written in a great^1 language without any packaging or distribution method other than "here's my container bruh". Like, ughh. ^1 Caveat, making a package of a Python project can be a rabbit hole can be a real pita. Virtual envs are usually good enough for most stuff until I start to need a compiler in every jail. Nowadays I'm looking almost only at Go (best) or Rust because their distribution is trivial in comparison.

ethagnawl 3y ago
I'm with you on pretty much all of what you've said. The _trivial distribution story_ is part of the reason I handed off maintenance of tmuxinator and started working on rmuxinator (spiritual successor written in Rust). Otherwise, I often find myself needing to deploy Python/Node/Ruby at $WORK and I'd really rather not try to get a bunch of dev/prod machines (possibly running different OSes!) trying to use whatever the flavor of the day for managing virtual environments, interpreter versions, packages, etc. is.

m463 3y ago

I would imagine that is a superset of all the others. I've spent waaay to much time trying to docker build a python container with various combinations of apt-get/pacman/apk + pip/conda/venv

ethagnawl 3y ago
You're right that it's not trivial if you're starting from scratch but, in theory, you only need to get it right once. Even if you did need to move to a different strategy in the future because pip stopped being included in your container's distro or something, that's a single point of failure and not something that needs to be sorted out on every dev/prod machine. To move up a level of abstraction, though, the official Python image pretty much does The Right Thing by default (copy requirements.txt, pip install, execute some command, etc.). Of course that isn't going to work for every scenario but it's a good place to start.

Brian_K_White 3y ago

A container is a shit way to package something. It's not a solution it's a response. It's "This thing makes no attempt to be portable or coordinate with the rest of the world, so the only way to package it is to include a copy of it's own entire world." There is no excuse for a python script to be a hothouse flower. It's one thing to choose to containerize something for your own operational reasons, but something else entirely for something to be so fragile that thst's the only way it even works is just you need a copy of the devs laptop. It's garbage.