uwsgi-nginx-flask-docker VS rules_python

I'm using a dockerimage based on https://github.com/tiangolo/uwsgi-nginx-flask-docker/tree/master/python3.6. I am running a python app inside that accepts a POST, does some processing on the json body, and returns a simple json response back. A post like this:

uwsgi-nginx-flask

I use this container for dev and testing purposes (though you could use it for production if it was hosted somewhere reliable). It spins up nice and easy, has everything you need for a functioning Flask web app, and is lightweight.

I have tried to enable threading to run the flask web server and a discord bot. The code runs fine in vscode on 127.0.0.1:5000 but when I git pull into a docker image it still runs on port 5000 and not on port 80.

What's SV?

I honestly don't know why anyone would use that... as in what does Bazel do better than virtually anything else that can provide this functionality. But, I used to be an ops engineer in a big company which wanted everything to be Maven, regardless of whether it does it well or not. So we built and deployed with Maven a lot of weird and unrelated stuff.

Not impossible, but not anything I'd advise anyone to do on their free time.

Specifically wrt' the link you posted, if you look here: https://github.com/bazelbuild/rules_python/blob/main/python/... it says that only pure Python wheels are supported, but that's also a lie, they don't support half of the functionality of pure Python wheels.

So, definitely not worth using, since lots of functionality is simply not there.

Regarding bazel, the rules_python has a py_wheel rule that helps you creating wheels that you can upload to pypi (https://github.com/bazelbuild/rules_python/blob/52e14b78307a...).

If you want to see an approach of bazel to pypi taken a bit to the extreme you can have a look at tensorflow on GitHub to see how they do it. They don't use the above-mentioned building rule because I think their build step is quite complicated (C/C++ stuff, Vida/ROCm support, python bindings, and multiOS support all in one before you can publish to pypi).

Python support in Bazel now looks more promising with `rules_python`: https://github.com/bazelbuild/rules_python

`rules_go` to my understanding is great too.

Over years, Bazel is not as opinionated as before, mostly because adoptions in different orgs force it to be so.

I have personally run converted build systems to Bazel, and use it for personal projects as well.

Bazel 1.0 was released in October 2019. If you were using it "a few years ago", I'm guessing you were using a pre-1.0 version. There's not some cutoff where Bazel magically got easy to use, and I still wouldn't describe it as "easy", but the problem it solves is hard to solve well, and the community support for Bazel has gotten a lot better over the past years.

https://github.com/bazelbuild/rules_python

The difficulty and complexity of using Bazel is highly variable. I've seen some projects where using Bazel is just super simple and easy, and some projects where using Bazel required a massive effort (custom toolchains and the like).

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") #------------------------------------------------------------------------------ # Python #------------------------------------------------------------------------------ # enable python rules http_archive( name = "rules_python", url = "https://github.com/bazelbuild/rules_python/releases/download/0.2.0/rules_python-0.2.0.tar.gz", sha256 = "778197e26c5fbeb07ac2a2c5ae405b30f6cb7ad1f5510ea6fdac03bded96cc6f", )