What a bizarrely arrogant (condescending) way to formulate arguments. "It is okay to feel provoked by this statement. As pointed out previously: you have probably invested a lot of time in Python. You will be inclined to justify and defend that investment. I would urge you to take some time to think about this and try to calm your urge to come up with counter-arguments. Let it sink in and try to be open to the possib…
Please do not use Python for tooling
11–20 of 84 posts
Re: Please do not use Python for tooling
#12Re: Please do not use Python for tooling
#13As for the section on python being antisocial, It makes sense to me. Dependency management is a tough thing for python and javascript. However I would not switch to writing Rust or Go for tooling scripts either.
Though Python has been used for devops scripts in at my job for a long time, and has been very very stable, so I'm not sure why it's causing so much pain for the author.
Re: Please do not use Python for tooling
#14Re: Please do not use Python for tooling
#15It was written in C++ using Qt.
Have you ever tried compiling a Qt program on Windows? It involves signing up for an official Qt developer account to even install qmake.
To the point I had to use an unofficial Qt installer CLI app (aqtinstall) [0] to even install the toolchain to build this little shitty app... which still relied on having several Qt .dll files in the same directory as the .exe to work.
Have you clicked on [0] yet? Well, then guess what programming language aqtinstall uses.
Re: Please do not use Python for tooling
#16Re: Please do not use Python for tooling
#17Earlier quoted context omitted.
Could you provide an example of how you solve the problems with Zephyr or ESP-IDF using virtualenv?
It appears ESP-IDF can already be installed with a virtualenv: https://github.com/espressif/esp-idf/blob/master/tools/idf_t... Perhaps your problems are due to external dependencies (outside of Python)?
One day I wish someone would train something like copilot to automatically bazel all your dependencies. There’s plenty of training data there and you can validate it by making sure the build flags are the same as the cmake or ./configure …
Re: Please do not use Python for tooling
#18Also don't use C or C++, i wasted so much time trying to compile stuff (no offence if you're a C dev). Also no Java please, how do I even install JVM on my system? Node and JavaScript, Ruby, Perl, Bash are out too of course. Bash sometimes works but what if I'm using a different shell?
I think a lot of the issue is that these languages love to install .directories in your home directory where all your libraries live and it works seamlessly for you.. but no one else.
We use python, perl and bash. Generally people who are more comfortable in one than the other just choose that language.
Re: Please do not use Python for tooling
#19I think tooling authors need to look into packaging. Python actually has something similar to JARs, zipapps [0], although I have yet to see them in the wild. PyInstaller is a more well-known option.
[0]: https://docs.python.org/3/library/zipapp.html#creating-stand...
Re: Please do not use Python for tooling
#20If we lived in a world in which most tooling (currently written as python scripts) were actually compiled, we'd be seeing better-reasoned essays begging us to write tooling as easily-editable scripts, rather than closed-off executables.
I have had scripts that I needed to edit just slightly almost every time I ran them. Having to involve a compile toolchain every time would have been terrible, and is exactly why I reached for Python in the first place.
I don't doubt the author has felt the pain of changing or missing Python dependencies. It seems likely they don't have a good understanding of pyenv or conda. The solution is not to choose something even worse: it's to write up a README on how to use conda!