| I worked for a company of ex-Googlers that used Bazel with Python/Django a few years ago. - It copies your files into a temporary directory to run them and that directory is named an obnoxiously long hash digest, so it effectively takes a giant shit in all your stack traces. When you're looking at an error message, half of your field of vision is taken up by line noise of the same random hash over and over again and since it runs your Python the first few frames are just helpfully telling you "this code was run through bazel". I even wrote a script that scanned my clipboard for Python stack traces, parsed them and removed this noise to make it easier on my brain to search for the actual line with the error. - Every import you write you have to write in two files or three if you have to export it. It's double the typing work and finding the target is a pain because there's no jump to definition of the Bazel target so it's even more typing to find it. - I wanted to use pytest and it was much more work, I don't think I ever got it working. Normally there's no setup you just run "pytest" and it discovers all the tests and runs them. - Your code doesn't start running as quickly. - You have to type way more characters to start your code. I had aliases for every endpoint. - There was something with tests where if the error log was too long it would just say "there was an error, please find it in this randomly-named file" and when you're debugging a test whose error log is too long it's going to be too long every time you re-run it too. So running and seeing the error is now a two step operation, double the work. Maybe some things have changed or I misremembered something, but overall it was the part of our tech stack I really hated. I just wrote software, I didn't do any ops or any sort of deployment or touched live systems at all really, so I honestly have no clue what it actually did for us it was just pure downside for me. I would never use it. |
Others are good points too. Thanks!