The official docs recommend doing many of the things the author cautions against or calls bad. https://packaging.python.org/en/latest/guides/distributing-p...
"Bonus: Legacy Outdated Python Usage Warning Signs" was a helpful list of things to look at, but I disagree with many as best practices. I like when code from the year 2000 still works, and you do that by using standard packages.
The chase for the latest / greatest means bitrot and is the sign of a junior developer. You save a bit of time in the short term, but a new latest / greatest comes out a few years later.
The conclusion is a bit weird too. That kind of rant is what leads to no-hire decisions. Be careful what you put online.
Seriously, first C and now Python.
I can't wait for the 20th revised version of this blog post where Matt has slowly realises he doesn't know half as much as he claims to and has added 50 side notes explaining all the cases where his blanket statement is not quite as broadly applicable as he ignorantly assumed.
Also, is the author aware of why people use Anaconda? Conda environments can make it significantly easier to link CUDA or Fortran libraries properly, which are quite prevalent in scientific computing. Many people who use such code bases are professional scientists and not professional programmers, so I understand seeing that generally conda-based packages are poorly architected.
It's almost like other people sometimes do things differently because they have different needs or have thought of things you haven't, not just because they're too stupid or uneducated to know better.
There seems to be a sea of alternatives and I see every tutorial mention `pip install` while I don't even have that running in my CLI (only pip3). Do people assume an alias here of I have somehow messed up my environment?
I realize the Venn of packaging has copious disjoint functionality slices.
Too, what one does for a bit of one-off, non-typed cloud manipulation is different than for a full-on, re-usable library.
But the fabulous disaster that is the python packaging landscape was tiresome a decade ago.
Maybe the PSF can sponsor a kickstarter so that peanut gallery mouths like mine can contribute funds where our skills are tapering off.
This bit towards the end certainly came out of left field, but made me laugh:
dawn your peepers on some of these fun adventures in hiring i’ve had recently:
rejected in interviews by a 25 year old senior hiring manager rejected in interviews by a 28-something who had worked at google for 5 years and had a PhD from stanford rejected for arguing, akshually, i made more 10 years ago than what your scale is rated at rejected by some founders who got rich by selling an ios fart app to apple ten years ago rejected via HR/email/auto-reject a couple places at least nobody has ever accused me of not being sufficiently candid.
- item 1
- item 2
???
The difference between UV and pixi is that pixi is better tooling for working with Conda repositories, and UV focuses in working with pip packages. Pixi allows installing not only pip packages but anything that has been packaged for Conda, which includes a lot of non-python stuff (C/C++ libraries and more).
For instance, I use it to install the Go compiler per-project, since using a global installation tends to grow "polluted" with every single go package that you have ever installed. You could even use it to install Node, NPM or ruby per-project, it just works. It also supports lock files [3].
--
2: https://prefix.dev/blog/uv_in_pixi
3: https://pixi.sh/latest/features/lockfile/#why-a-lock-file
I found that direnv [1] really improved the ergonomics for me. There's some misunderstanding that direnv requires Nix but that's not true. It does one thing and does it well: load .envrc files when you cd that path.
I have a lil `.envrc` that looks like this:
# Load pixi shell settings.
eval "$(pixi shell-hook -s bash)"
--
This situation is also partially why there is so much python tooling around versions, environments and dependencies.
I would love to have a little less dynamic Python, that could be compiled to not huge binaries.
Oof. Yikes. Outdated much? I kid, but it's way too easy to be dogmatic about stuff like libs.
Rye on the other hand seems to be extremely poetry-like while being written in rust for speed: https://rye.astral.sh/
But personally, I can't justify switching my employer to experimental python dependency management over something as inconsequential as taking a minute to install dependencies so I'm sticking to poetry until Rye has some years of development behind it.