4 ms·
The perspective I'm trying to shine a light on is what it is like to be the consumer of tooling written in Python - not the author. I was a bit unclear in the
by bborud 4y ago
The perspective I'm trying to shine a light on is what it is like to be the consumer of tooling written in Python - not the author.
I was a bit unclear in the title (which is what most people seem to have read, and then skimmed the blog posting), but the tooling I'm talking about is things like the `west` tool for Zephyr or the `idf.py` tool for ESP-IDF. Tools that are centrally maintained and distributed. Not the ad-hoc tools people use to do various chores in their codebases.
Both of the tools mentioned are notorious for being extremely brittle. Actually, as we speak, I'm trying to figure out why a project that worked before I left on vacation, and which has been untouched for several weeks, now suddenly doesn't build (because the tooling doesn't run). This is actually par for the course. You have to expect things to break for no obvious reason. My guess? I probably updated some other piece of software and it upgraded a common dependency.
I spend about 10-20% of my time dealing with this sort of nonsense.
- bccdee 4y agoIt sounds like your main issue is that you don't isolate your dependencies into virtual environments. That involves jumping through a couple hoops, sure (primarily just invoking `./venv/bin/activate` before you run the script), but for the most part it entirely resolves Python dependency problems. Could Python's dependency management be less clunky? Absolutely. But ultimately, when it comes to the tools you mentioned, the vendor is the one responsible for not explaining proper Python dependency management in their documentation, or for not creating an ergonomic wrapper around it.
- bb88 4y agoIf you have issues like that, definitely look into virtualenvs and requirements.txt. It's meant to isolate python environments from breaking like that.