I'm still using it with not a single issue (except when is messes up the iptables rules)

I still confidently, upgrade the docker across all the nodes, workers and managers and it just works. Not a single time that it caused an issue.

No wonder they made iPhone pocket now.

They should make tshirts for their laptops as well.

The ridiculous part is, people will buy this.

To be honest, I never liked the way async is done in python at all.

However, I love Django and Python in general. When I need "async" in a http cycle flow, I use celery and run it in background.

If client side needs to be updated about the state of the background task, the best is to send the data to a websocket channel known to the client side. Either it's Chat response with LLM or importing a huge CSV file.

Simple rule for me is, "don't waste HTTP time, process quick and return quick".

This feature works as long as your venv that uv creates and the uv cache (in user home directory, or anywhere else that is configured to keep the cache folder) are both on the same filesystem.

The drive where the venv was created was NTFS and the user home directory where uv cache exists was ext4 file system.

Therefore the caching didn't work and a warning was shown by uv hinting to the problem.

While I like the idea of pip or uv to be insanely fast, I still don't see it revolutionize my development experience.

Installing and uninstalling package is not something I do every 1 to 10 minutes. It doesn't save me any much time. Also, activating a venv is once a session in terminal and sometime a week goes by without ever activating a venv, because the IDE does that automatically on whatever I do.

That's why, personally for me it really doesn't change much.

Where I like things being fast in my development time is pre-commit and linting, where ruff shines. Which that I also don't use, even though I work on a small-medium 600k LoC project, I only pass the changed files to isort, flake8 and black and it's all done in less than 5 seconds.

To me, the only advantage of uv is being fast, which is something I haven't been bothered with so far, where 99% of things happen in less than 1 or max couple of seconds.

I noticed the comment from andy99 got several downvotes (became grey) and mine here also immediately got some.

On my machine, there are like 100s of not thousands of venvs.

I simply have all of them under ~/.python_venvs//

Does that mean, no matter how many projects I install pytorch and tensoflow and huggingface and all the heavy machinery, they'll be counted only once as long as they're unique?

If that's the case, then I can leave my habit of pip and move to uv.

This is something that always bugged my mind about virtual environments in almost all the package managers.

Rarely I'd need a different version of python, in case I do, either I let the IDE to take care of it or just do pyenv.

I know there's the argument of being fast with uv, but most of the time, the actual downloading is the slowest part.

I'm not sure how big a project should be, before I feel pip is slow for me.

Currently, I have a project with around 50 direct dependencies and everything is installed in less than a min with a fresh venv and without pip cache.

Also, if I ever, ever needed lock files stuff, I use pipx. Never needed the hash of the packages the way it's done in package-lock.json.

Maybe, I'm just not the target audience of uv.

Introducing new keyword has become a recent thing in Python.

Seems Python has a deep scare since Python2 to Python3 time and is scared to do anything that causes such drama again.

For me, the worst of all is "async". If 2to3 didn't cause much division, the async definitely divided Python libraries in 2. Sync and Async.

Maybe if they want backward compatible solution, this can be done by some compile or runtime flag like they did with free threading no-gil.

I know/heard there are "some" (which I haven't seen by the way) libraries that depend on import side effects, but the advantage is much bigger.

First of all, the circular import problem will go away, especially on type hints. Although there was a PEP or recent addition to make the annotation not not cause such issue.

Second and most important of all, is the launch time of Python applications. A CLI that uses many different parts of the app has to wait for all the imports to be done.

The second point becomes a lot painful when you have a large application, like a Django project where the auto reload becomes several seconds. Not only auto reload crawls, the testing cycle is slow as well. Every time you want to run test command, it has to wait several seconds. Painful.

So far the solution has been to do the lazy import by importing inside the methods where it's required. That is something, I never got to like to be honest.

Maybe it will be fixed in Python 4, where the JIT uses the type hints as well /s

TBH, I've seen tutorials or even some companies simply do `pip freeze > requirements.txt` :shrug: which is a mess.

`pyproject.toml` let's you set the min python version. If not met, it won't install.

Regardless, majority of the times, deployment is done via Docker.

I create a venv. Pip install and keep my direct deps in requirements.txt

That's it. Never understood all these python dependency management problems dramas.

Recently, I started using pyproject.toml as well which makes the whole thing more compact.

I make lots of python packages too. Either I go setup.py or sometimes I like to use flit for no specific reason.

I haven't ever felt the need for something like uv. I'm good with pip.

This. Very much this.

I have given up on one finding such. The closest and nicest one that comes to mind is SQLAlchemy. The rest of languages or frameworks have indeed nothing compared to Django ORM and SQLAlchemy. It's not even fair to compare them.

Regarding read only models pointing to a tabel. It'd possible to use proxy models or even non managed models where with some mix of Managers it can provide what you're looking for.

For getting a subset of fields from a database tabel, Django provides ".only()" on the QuerySet which you can use to list all the fields explicitly and only them will be retrieved. It can even span to foreign field relations as well.

Diango ORM is indeed powerful and vrry flexible once you learn it. A novice developer can use it quickly and won't get in the way. An advanced developer can do very complex sfuff with it without touching any raw sql. Still, it's possible to write custom sql commands directly.

and first in line advocate to sanction Iran even in time of covid.

You say something against the mainstream media or US hegemony, you'll b labeled as Basiji or "iranian regime supporter" or "on Putin payroll".

Not a place for thinking even epsilon out of tunneled vision made by westerners propaganda machine.

After all, majority are the ones that gonna rewrite their project in different language or stack because "the landing page said so"

Has been said for the last 44 years.