8 ms·

Switching Pip to Uv in a Dockerized Flask / Django App

273 points by tosh 1y ago

j4mie 1y ago
It's worth noting that uv also supports a workflow that directly replaces pyenv, virtualenv and pip without mandating a change to a lockfile/pyproject.toml approach. uv python pin <version> will create a .python-version file in the current directory. uv virtualenv will download the version of Python specified in your .python-version file (like pyenv install) and create a virtualenv in the current directory called .venv using that version of Python (like pyenv exec python -m venv .venv) uv pip install -r requirements.txt will behave the same as .venv/bin/pip install -r requirements.txt. uv run <command> will run the command in the virtualenv and will also expose any env vars specified in a .env file (although be careful of precedence issues: https://github.com/astral-sh/uv/issues/9465 https://github.com/astral-sh/uv/issues/9465)
- slau 1y ago
  uv and its flexibility is an a absolute marvel. Where pip took 10 minutes, uv can handle it in 20-30s.
  - ljm 1y ago
    It’s an absolute godsend. I thought poetry was a nice improvement but it had its flaws as well (constant merge conflicts in the lock file in particular). Uv works more or less the same as I’m used to with other tooling in Ruby, JS, Rust, etc.
    - robertlagrant 1y ago
      How does uv avoid merge conflicts in lock files? I need a reason to switch.
      - ljm 1y ago
        I never got a chance to see the difference there because I moved on shortly after. It was just that almost constant conflicts with poetry (and the errors about the project being out of sync) with a team developing in parallel were painful enough for me to suggest we try uv instead. It seemed uniformly better with a simpler docker setup too (although I liked how pants would created executable bundles and you could just ship those).
        robertlagrant 1y ago
        Fair enough! I'm a bit surprised that anyone could get regular out of sync errors unless a team member were constantly updating dependencies every commit. But then if they did that with uv I'd imagine they'd have the same issue. Unless uv does something extra smart and creates you a new environment for every git branch.
- politelemon 1y ago
  Doesn't it store the python version in the pyproject.toml though, is the python version file needed?
  - JimDabell 1y ago
    It’s not: > uv will respect Python requirements defined in requires-python in the pyproject.toml file during project command invocations. The first Python version that is compatible with the requirement will be used, unless a version is otherwise requested, e.g., via a .python-version file or the --python flag. — https://docs.astral.sh/uv/concepts/python-versions/#project-python-versions https://docs.astral.sh/uv/concepts/python-versions/#project-...
    - politelemon 1y ago
      cheers
  - deleted 1y ago
    [deleted]
- smeeth 1y ago
  +1, this is the exact reason I started using uv. Extremely convenient. For some reason uv pip has been very slow, however. Unsure why, might be my org doing weird network stuff.
  - greenavocado 1y ago
    Or very difficult package spec
gchamonlive 1y ago
# Ensure we always have an up to date lock file. if ! test -f uv.lock || ! uv lock --check 2>/dev/null; then uv lock fi Doesn't this defeat the purpose of having a lock file? If it doesn't exist or if it's invalid something catastrophic happened to the lock file and it should be handled by someone familiar with the project. Otherwise, why have a lock file at all? The CI will silently replace the lock file and cause potential confusion.
- freetonik 1y ago
  In the Python world, I often see lockfiles treated a one "weird step in the installation process", and not committed to version control.
  - burnt-resistor 1y ago
    In the almost every world, Ruby and elsewhere too, constraints in library package metadata are supposed to express the full supported possibilities of allowed constraints while lock files represent current specific state. That's why they're not committed in that case to allow greater flexibility/interoperability for downstream users. For applications, it's recommended (but still optional) to commit lock files so that very specific and consistent dependencies are maintained to prevent arbitrary, unsupervised package upgrades leading to breakage.
    - MrJohz 1y ago
      I know Cargo recommended your approach for a while, but ended up recommending that all projects always check in a lock file. This is also the norm in most other ecosystems I've used including Javascript and other Python package managers. When you're developing a library, you still want consistent, reproducible dependency installs. You don't want, for example, a random upgrade to a testing library to break your CI pipelines or cause delays while releasing. So you check in the lock file for the people working on the library. But when someone installs the library via a package manager, that package manager will ignore the lock file and just use the constraints in the package metadata. This avoids any interoperability issues for downstream users. I've heard of setups where there are even multiple lock files checked in so different combinations of dependency can be tested in CI, but I've not seen that in practice, and I imagine it's very much dependent on how the ecosystem as a whole operates.
bsenftner 1y ago
I'd like to see a security breakdown of uv versus pip versus conda versus whatever fashionable package manager I've not heard of yet. Speed is okay, but security of a package manager is far more important.
- Bengalilol 1y ago
  uv is generally more secure than pip. It resolves dependencies without executing arbitrary code, verifies package hashes by default, and avoids common risks like typosquatting and code execution during install. It's also faster and more reproducible. https://chaitalks.tech/uv-a-modern-python-package-manager-inspired-by-cargo/ https://chaitalks.tech/uv-a-modern-python-package-manager-in... https://docs.astral.sh/uv/pip/compatibility/ https://docs.astral.sh/uv/pip/compatibility/
  - glaucon 1y ago
    I'd be interested to know under what circumstances pip executes arbitrary code while resolving dependencies ... how does that work ? And while I'm here ... how does uv go about mitigating typosquatting risks ? I could imagine how it might issue warnings if you perhaps it notices you requesting "dlango", which would work OK for the top 10% but are you suggesting there's some more general solution built into uv ? I did a quick search but 'typosquatting' is not an easy string to cut through.
    - alexchamberlain 1y ago
      For a source package based on setup tools, setup.py is executed with a minimal environment and can run arbitrary code.
      - ericvsmith 1y ago
        You can (and should!) tell pip not to do this with '--only-binary=:all:'. Building from source is a lousy default.
0xbadcafebee 1y ago
Some thoughts on the patterns here: - Removing requirements.txt makes it harder to track the high-level deps your code requires (and their install options/flags). Typically requirements.txt should be the high level requirements, and you should pass them to another process that produces pinned versions. You regenerate the pinned versions/deps from the requirements.txt, so you have a way to reset all dependencies as your core ones gain or lose nested dependencies. - +COPY --from=ghcr.io/astral-sh/uv:0.7.13 /uv /uvx /usr/local/bin/ seems useful, but the upstream docker tag could be repinned on a different hash, causing conflicts. Use the hash, or use a different way to stage your dependencies and copy them into the file. Whenever possible, confirm your artifacts match known hashes. - Installing into the container's /home/project/.local may preserve the uv pattern, but it's going to make a container that's harder to debug. Production containers (if not all containers) should install files into normal global paths so that it's easy to find the, reason about them, and use standard tools to troubleshoot. This allows non-uv users to diagnose the application running, and removes extra abstraction layers which create unneeded complexity. - +RUN chmod 0755 bin/ && bin/uv-install* - using scripts makes things easier to edit, but it makes it harder to understand what's going on in a container, because you have to run around the file tree reading files and building a mental map of execution. Whenever possible, just shove all the commands into RUN lines in the Dockerfile. This allows a user to just view the Dockerfile and know the entire execution without extra effort. It also removes some complexity in terms of checking out files, building Docker context, etc. - Try to avoid docker compose and other platform-constrained tools for the running of your tests, for the freezing of versions, etc. You SDLC should first be composed of your build tools/steps using just native tools/environments. Then on top of that should go the CI tools. This separation of "dev/test environment" from CI allows you to take your "dev/test environment" and run it on any CI platform - Docker Compose, GitHub Actions, CircleCI, GitLab CI, Jenkins, etc - without modifying the "dev/test environment" tools or workflow. Personally I have a dev.sh that sets up the dev environment, build.sh to run any build steps, test.sh to run all the test stuff, ci.sh to run ci/cd specific stuff (it just calls the CI/CD system's API and waits for status), and release.sh to cut new releases.
- IgorPartola 1y ago
  Agreed, custom scripts are great for the person who wrote them and/or uses them all the time but I much prefer to add as little veneer over upstream tools as possible lest I get messages like “hey how do I actually restart this process/get these logs/upgrade this package?” Only thing I’m not sure about: why is having your list of requirements in requirements.txt vs project.toml? Isn’t it just one file vs another?
0xblinq 1y ago
2025 and python packaging and dependencies management is still a mess.
- incognito124 1y ago
  It's only a mess because not everyone has adopted uv yet (IMO)
  - soulofmischief 1y ago
    Python package management is a classic example of xkcd #927, and the community cannot be blamed for developing a Pavlovian response when it comes to yet-another-package-manager that promises to be the final solution.
  - greener_grass 1y ago
    UV looks very promising but I can assure you, if everyone adopted it tomorrow we would see a long tail of scenarios that UV does not work well for.
    - bckr 1y ago
      I would love to see that happen and see how astral responds. I would love to see uv get built into Python 4
    - tempest_ 1y ago
      I am perfectly content for a 90% solution, we should not let the perfect be the enemy of the good.
  - 0xblinq 1y ago
    It’s a mess because there’s no first party, properly thought out and working solution. So every year we get a new “new way” to do it. Like that xkcd… this time this is the standard that will work!
- ericfrederich 1y ago
  Yes, it's a mess (New: now with Rust!)
b0a04gl 1y ago
[dead]
cmiller1 1y ago
I have software people use up on pypi and I'd love to switch to uv for personal use to benefit from the improved speed but I'd need some guarantees that things work EXACTLY how they work on pip or that I could run them concurrently. If I put instructions up for users to "just run pip install xxx" I need to know that if they see any errors I can see those too for debugging/troubleshooting.
- oblvious-earth 1y ago
  It does not work EXACTLY how pip works, big differences are covered here: https://docs.astral.sh/uv/pip/compatibility/ https://docs.astral.sh/uv/pip/compatibility/ Some of these are uv following the standards while pip is still migrating away from legacy behavior, some of these are design choices that uv has made, because the standard is underdefined, it's a tool specific choice, or uv decided not to follow the standards for whatever reason.
ericfrederich 1y ago
I am totally against Python tooling being written in a language other than Python. I get that C extensions exist and for the most part Python is synonymous with CPython. I think 2 languages are enough, we don't need a 3rd one that nobody asked for. I have nothing against Rust. If you want a new tool, go for it. If you want a re-write of an existing tool, go for it. I'm against it creeping into an existing eco-system for no reason. A popular Python package called Pendulum went over 7 months without support for 3.13. I have to imagine this is because nobody in the Python community knew enough Rust to fix it. Had the native portion of Pendulum been written in C I would have fixed it myself. https://github.com/python-pendulum/pendulum/issues/844 https://github.com/python-pendulum/pendulum/issues/844 In my ideal world if someone wanted fast datetimes written in Rust (or any other language other than C) they'd write a proper library suitable for any language to consume over FFI. So far this Rust stuff has left a bad taste in my mouth and I don't blame the Linux community for being resistant.
- moolcool 1y ago
  > I am totally against Python tooling being written in a language other than Python I will be out enjoying the sunshine while you are waiting for your Pylint execution to finish
  - throwawaysleep 1y ago
    Linting is the new "compiling!"
  - lillecarl 1y ago
    Linting and type checking are very CPU intensive tasks so I would excuse anyone implementing those types of tools in $LANG where using all CPU juice matters. I can't help but think uv is fast not because it's written in Rust but because it's a fast reimplementation. Dependency solving in the average Python project is hardly computationally expensive, it's just downloading and unpacking packages with a "global" package cache. I don't see why uv couldn't have been implemented in Python and be 95% as fast. Edit: Except implementing uv in Python requires shipping a Python interpreter kinda defeating some of it's purpose of being a package manager able to install Python as well.
deleted 1y ago
[deleted]
bodge5000 1y ago
I really like uv, easily my favourite Python package manager, but the last time I tried it with Docker and Django it was a nightmare, particularly with environment variables for some reason. Maybe this will help
ing33k 1y ago
UV just works. Easily one of the best things to happen to Python packaging in years.
nodesocket 1y ago
Is there no apt repo to install uv? My Docker builds using pip take around 2 minutes, not sure the juice is worth the squeeze upgrading to uv. Current Dockerfile pip is as simple as: COPY --chown=python:python requirements.txt . RUN pip install --no-cache-dir --upgrade pip && \ pip install --no-cache-dir --compile -r requirements.txt COPY --chown=python:python . . RUN python -m compileall -f .
- cpburns2009 1y ago
  uv is not in Debian's or Ubuntu's apt repositories to my knowledge. What I do instead because I don't like piping shell scripts from URLs is "pip install --upgrade pip uv", and then run "uv pip ...".
- zanie 1y ago
  Installation in Docker just looks like COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/ https://docs.astral.sh/uv/guides/integration/docker/#using-uv-in-docker https://docs.astral.sh/uv/guides/integration/docker/#using-u... (We'd recommend pinning the version or SHA in production)
- remram 1y ago
  With a cache directory that can be 0 minute. RUN --mount=type=cache,target=/root/.cache/pip pip install ...
ndr 1y ago
PSA careful replacing `pip` with `uv` thinking it's a drop-in replacement. By default `uv` won't generate `pyc` files which might make your service much slower to start. See https://docs.astral.sh/uv/reference/settings/#pip_compile-bytecode https://docs.astral.sh/uv/reference/settings/#pip_compile-by...
- elyall 1y ago
  uv's guide for use in containers is a better reference for this: https://docs.astral.sh/uv/guides/integration/docker/#compiling-bytecode https://docs.astral.sh/uv/guides/integration/docker/#compili...
  - ndr 1y ago
    Agreed if you're going there from the start. I stumbled on this by porting something using that was previously pip, and that surprisingly different default has been a foot gun.
rowanseymour 1y ago
I got excited about poetry a few years back because it seemed that the community might be finally able to rally around _one_ packaging solution. My favorite thing about Go is that there isn't a shiny new packaging tool every year.. just go.mod. uv definitely looks cool and the performance is very impressive.. but should I switch all my projects over? Are you going to be around in 5 years time?
- frankwiles 1y ago
  It takes 5 minutes to switch most projects. And less to go back to pip. Seems silly to waste a bunch of wall time when using pip when there is a super easy alternative that doesn't have high switching costs.
  - rowanseymour 1y ago
    Ok but that's really not the cost for a company that's been using tool X for years, accumulated some expertise in that, built their own tooling on top of it etc.
- bckr 1y ago
  Just try it. The hype is real. I stopped using pyenv, pyenv-virtualenv, poetry, and native pip because uv is just that sticky. Just install it and try running something using the —-with flag. That’s where I became intrigued.
adolph 1y ago
What is Astral's economic model? This is my primary hesitation to full adoption. Is Astral's future the same story as Anaconda?
- steveklabnik 1y ago
  https://news.ycombinator.com/item?id=44358216 https://news.ycombinator.com/item?id=44358216
  - adolph 1y ago
    Ok, same story as Anaconda but they haven't gotten as far.
jdboyd 1y ago
What originally convinced me to try uv was the promise of faster container builds, and it certainly delivered on that. As someone who usually used platform pythons, despite advise against that, uv is now what got me to finally stop doing so.
kh_hk 1y ago
Just generate a requirements.txt with uv, ship that with docker, and then there's no need for all this dance
nrvn 1y ago
also a great guide for building production-ready containers using uv: https://hynek.me/articles/docker-uv/ https://hynek.me/articles/docker-uv/

273 points by tosh 1y ago

It's worth noting that uv also supports a workflow that directly replaces pyenv, virtualenv and pip without mandating a change to a lockfile/pyproject.toml approach. uv python pin <version> will create a .python-version file in the current directory. uv virtualenv will download the version of Python specified in your .python-version file (like pyenv install) and create a virtualenv in the current directory called .venv using that version of Python (like pyenv exec python -m venv .venv) uv pip install -r requirements.txt will behave the same as .venv/bin/pip install -r requirements.txt. uv run <command> will run the command in the virtualenv and will also expose any env vars specified in a .env file (although be careful of precedence issues: https://github.com/astral-sh/uv/issues/9465 https://github.com/astral-sh/uv/issues/9465)

slau 1y ago
uv and its flexibility is an a absolute marvel. Where pip took 10 minutes, uv can handle it in 20-30s.
- ljm 1y ago
  It’s an absolute godsend. I thought poetry was a nice improvement but it had its flaws as well (constant merge conflicts in the lock file in particular). Uv works more or less the same as I’m used to with other tooling in Ruby, JS, Rust, etc.
  - robertlagrant 1y ago
    How does uv avoid merge conflicts in lock files? I need a reason to switch.
    - ljm 1y ago
      I never got a chance to see the difference there because I moved on shortly after. It was just that almost constant conflicts with poetry (and the errors about the project being out of sync) with a team developing in parallel were painful enough for me to suggest we try uv instead. It seemed uniformly better with a simpler docker setup too (although I liked how pants would created executable bundles and you could just ship those).
      - robertlagrant 1y ago
        Fair enough! I'm a bit surprised that anyone could get regular out of sync errors unless a team member were constantly updating dependencies every commit. But then if they did that with uv I'd imagine they'd have the same issue. Unless uv does something extra smart and creates you a new environment for every git branch.
politelemon 1y ago
Doesn't it store the python version in the pyproject.toml though, is the python version file needed?
- JimDabell 1y ago
  It’s not: > uv will respect Python requirements defined in requires-python in the pyproject.toml file during project command invocations. The first Python version that is compatible with the requirement will be used, unless a version is otherwise requested, e.g., via a .python-version file or the --python flag. — https://docs.astral.sh/uv/concepts/python-versions/#project-python-versions https://docs.astral.sh/uv/concepts/python-versions/#project-...
  - politelemon 1y ago
    cheers
- deleted 1y ago
  [deleted]
smeeth 1y ago
+1, this is the exact reason I started using uv. Extremely convenient. For some reason uv pip has been very slow, however. Unsure why, might be my org doing weird network stuff.
- greenavocado 1y ago
  Or very difficult package spec

gchamonlive 1y ago

# Ensure we always have an up to date lock file. if ! test -f uv.lock || ! uv lock --check 2>/dev/null; then uv lock fi Doesn't this defeat the purpose of having a lock file? If it doesn't exist or if it's invalid something catastrophic happened to the lock file and it should be handled by someone familiar with the project. Otherwise, why have a lock file at all? The CI will silently replace the lock file and cause potential confusion.

freetonik 1y ago
In the Python world, I often see lockfiles treated a one "weird step in the installation process", and not committed to version control.
- burnt-resistor 1y ago
  In the almost every world, Ruby and elsewhere too, constraints in library package metadata are supposed to express the full supported possibilities of allowed constraints while lock files represent current specific state. That's why they're not committed in that case to allow greater flexibility/interoperability for downstream users. For applications, it's recommended (but still optional) to commit lock files so that very specific and consistent dependencies are maintained to prevent arbitrary, unsupervised package upgrades leading to breakage.
  - MrJohz 1y ago
    I know Cargo recommended your approach for a while, but ended up recommending that all projects always check in a lock file. This is also the norm in most other ecosystems I've used including Javascript and other Python package managers. When you're developing a library, you still want consistent, reproducible dependency installs. You don't want, for example, a random upgrade to a testing library to break your CI pipelines or cause delays while releasing. So you check in the lock file for the people working on the library. But when someone installs the library via a package manager, that package manager will ignore the lock file and just use the constraints in the package metadata. This avoids any interoperability issues for downstream users. I've heard of setups where there are even multiple lock files checked in so different combinations of dependency can be tested in CI, but I've not seen that in practice, and I imagine it's very much dependent on how the ecosystem as a whole operates.

bsenftner 1y ago

I'd like to see a security breakdown of uv versus pip versus conda versus whatever fashionable package manager I've not heard of yet. Speed is okay, but security of a package manager is far more important.

Bengalilol 1y ago
uv is generally more secure than pip. It resolves dependencies without executing arbitrary code, verifies package hashes by default, and avoids common risks like typosquatting and code execution during install. It's also faster and more reproducible. https://chaitalks.tech/uv-a-modern-python-package-manager-inspired-by-cargo/ https://chaitalks.tech/uv-a-modern-python-package-manager-in... https://docs.astral.sh/uv/pip/compatibility/ https://docs.astral.sh/uv/pip/compatibility/
- glaucon 1y ago
  I'd be interested to know under what circumstances pip executes arbitrary code while resolving dependencies ... how does that work ? And while I'm here ... how does uv go about mitigating typosquatting risks ? I could imagine how it might issue warnings if you perhaps it notices you requesting "dlango", which would work OK for the top 10% but are you suggesting there's some more general solution built into uv ? I did a quick search but 'typosquatting' is not an easy string to cut through.
  - alexchamberlain 1y ago
    For a source package based on setup tools, setup.py is executed with a minimal environment and can run arbitrary code.
    - ericvsmith 1y ago
      You can (and should!) tell pip not to do this with '--only-binary=:all:'. Building from source is a lousy default.

0xbadcafebee 1y ago

Some thoughts on the patterns here: - Removing requirements.txt makes it harder to track the high-level deps your code requires (and their install options/flags). Typically requirements.txt should be the high level requirements, and you should pass them to another process that produces pinned versions. You regenerate the pinned versions/deps from the requirements.txt, so you have a way to reset all dependencies as your core ones gain or lose nested dependencies. - +COPY --from=ghcr.io/astral-sh/uv:0.7.13 /uv /uvx /usr/local/bin/ seems useful, but the upstream docker tag could be repinned on a different hash, causing conflicts. Use the hash, or use a different way to stage your dependencies and copy them into the file. Whenever possible, confirm your artifacts match known hashes. - Installing into the container's /home/project/.local may preserve the uv pattern, but it's going to make a container that's harder to debug. Production containers (if not all containers) should install files into normal global paths so that it's easy to find the, reason about them, and use standard tools to troubleshoot. This allows non-uv users to diagnose the application running, and removes extra abstraction layers which create unneeded complexity. - +RUN chmod 0755 bin/ && bin/uv-install* - using scripts makes things easier to edit, but it makes it harder to understand what's going on in a container, because you have to run around the file tree reading files and building a mental map of execution. Whenever possible, just shove all the commands into RUN lines in the Dockerfile. This allows a user to just view the Dockerfile and know the entire execution without extra effort. It also removes some complexity in terms of checking out files, building Docker context, etc. - Try to avoid docker compose and other platform-constrained tools for the running of your tests, for the freezing of versions, etc. You SDLC should first be composed of your build tools/steps using just native tools/environments. Then on top of that should go the CI tools. This separation of "dev/test environment" from CI allows you to take your "dev/test environment" and run it on any CI platform - Docker Compose, GitHub Actions, CircleCI, GitLab CI, Jenkins, etc - without modifying the "dev/test environment" tools or workflow. Personally I have a dev.sh that sets up the dev environment, build.sh to run any build steps, test.sh to run all the test stuff, ci.sh to run ci/cd specific stuff (it just calls the CI/CD system's API and waits for status), and release.sh to cut new releases.

IgorPartola 1y ago
Agreed, custom scripts are great for the person who wrote them and/or uses them all the time but I much prefer to add as little veneer over upstream tools as possible lest I get messages like “hey how do I actually restart this process/get these logs/upgrade this package?” Only thing I’m not sure about: why is having your list of requirements in requirements.txt vs project.toml? Isn’t it just one file vs another?

0xblinq 1y ago

2025 and python packaging and dependencies management is still a mess.

incognito124 1y ago
It's only a mess because not everyone has adopted uv yet (IMO)
- soulofmischief 1y ago
  Python package management is a classic example of xkcd #927, and the community cannot be blamed for developing a Pavlovian response when it comes to yet-another-package-manager that promises to be the final solution.
- greener_grass 1y ago
  UV looks very promising but I can assure you, if everyone adopted it tomorrow we would see a long tail of scenarios that UV does not work well for.
  - bckr 1y ago
    I would love to see that happen and see how astral responds. I would love to see uv get built into Python 4
  - tempest_ 1y ago
    I am perfectly content for a 90% solution, we should not let the perfect be the enemy of the good.
- 0xblinq 1y ago
  It’s a mess because there’s no first party, properly thought out and working solution. So every year we get a new “new way” to do it. Like that xkcd… this time this is the standard that will work!
ericfrederich 1y ago
Yes, it's a mess (New: now with Rust!)

b0a04gl 1y ago

[dead]

cmiller1 1y ago

I have software people use up on pypi and I'd love to switch to uv for personal use to benefit from the improved speed but I'd need some guarantees that things work EXACTLY how they work on pip or that I could run them concurrently. If I put instructions up for users to "just run pip install xxx" I need to know that if they see any errors I can see those too for debugging/troubleshooting.

oblvious-earth 1y ago
It does not work EXACTLY how pip works, big differences are covered here: https://docs.astral.sh/uv/pip/compatibility/ https://docs.astral.sh/uv/pip/compatibility/ Some of these are uv following the standards while pip is still migrating away from legacy behavior, some of these are design choices that uv has made, because the standard is underdefined, it's a tool specific choice, or uv decided not to follow the standards for whatever reason.

ericfrederich 1y ago

I am totally against Python tooling being written in a language other than Python. I get that C extensions exist and for the most part Python is synonymous with CPython. I think 2 languages are enough, we don't need a 3rd one that nobody asked for. I have nothing against Rust. If you want a new tool, go for it. If you want a re-write of an existing tool, go for it. I'm against it creeping into an existing eco-system for no reason. A popular Python package called Pendulum went over 7 months without support for 3.13. I have to imagine this is because nobody in the Python community knew enough Rust to fix it. Had the native portion of Pendulum been written in C I would have fixed it myself. https://github.com/python-pendulum/pendulum/issues/844 https://github.com/python-pendulum/pendulum/issues/844 In my ideal world if someone wanted fast datetimes written in Rust (or any other language other than C) they'd write a proper library suitable for any language to consume over FFI. So far this Rust stuff has left a bad taste in my mouth and I don't blame the Linux community for being resistant.

moolcool 1y ago
> I am totally against Python tooling being written in a language other than Python I will be out enjoying the sunshine while you are waiting for your Pylint execution to finish
- throwawaysleep 1y ago
  Linting is the new "compiling!"
- lillecarl 1y ago
  Linting and type checking are very CPU intensive tasks so I would excuse anyone implementing those types of tools in $LANG where using all CPU juice matters. I can't help but think uv is fast not because it's written in Rust but because it's a fast reimplementation. Dependency solving in the average Python project is hardly computationally expensive, it's just downloading and unpacking packages with a "global" package cache. I don't see why uv couldn't have been implemented in Python and be 95% as fast. Edit: Except implementing uv in Python requires shipping a Python interpreter kinda defeating some of it's purpose of being a package manager able to install Python as well.

deleted 1y ago

[deleted]

bodge5000 1y ago

I really like uv, easily my favourite Python package manager, but the last time I tried it with Docker and Django it was a nightmare, particularly with environment variables for some reason. Maybe this will help

ing33k 1y ago

UV just works. Easily one of the best things to happen to Python packaging in years.

nodesocket 1y ago

Is there no apt repo to install uv? My Docker builds using pip take around 2 minutes, not sure the juice is worth the squeeze upgrading to uv. Current Dockerfile pip is as simple as: COPY --chown=python:python requirements.txt . RUN pip install --no-cache-dir --upgrade pip && \ pip install --no-cache-dir --compile -r requirements.txt COPY --chown=python:python . . RUN python -m compileall -f .

cpburns2009 1y ago
uv is not in Debian's or Ubuntu's apt repositories to my knowledge. What I do instead because I don't like piping shell scripts from URLs is "pip install --upgrade pip uv", and then run "uv pip ...".
zanie 1y ago
Installation in Docker just looks like COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/ https://docs.astral.sh/uv/guides/integration/docker/#using-uv-in-docker https://docs.astral.sh/uv/guides/integration/docker/#using-u... (We'd recommend pinning the version or SHA in production)
remram 1y ago
With a cache directory that can be 0 minute. RUN --mount=type=cache,target=/root/.cache/pip pip install ...

ndr 1y ago

PSA careful replacing `pip` with `uv` thinking it's a drop-in replacement. By default `uv` won't generate `pyc` files which might make your service much slower to start. See https://docs.astral.sh/uv/reference/settings/#pip_compile-bytecode https://docs.astral.sh/uv/reference/settings/#pip_compile-by...

elyall 1y ago
uv's guide for use in containers is a better reference for this: https://docs.astral.sh/uv/guides/integration/docker/#compiling-bytecode https://docs.astral.sh/uv/guides/integration/docker/#compili...
- ndr 1y ago
  Agreed if you're going there from the start. I stumbled on this by porting something using that was previously pip, and that surprisingly different default has been a foot gun.

rowanseymour 1y ago

I got excited about poetry a few years back because it seemed that the community might be finally able to rally around _one_ packaging solution. My favorite thing about Go is that there isn't a shiny new packaging tool every year.. just go.mod. uv definitely looks cool and the performance is very impressive.. but should I switch all my projects over? Are you going to be around in 5 years time?

frankwiles 1y ago
It takes 5 minutes to switch most projects. And less to go back to pip. Seems silly to waste a bunch of wall time when using pip when there is a super easy alternative that doesn't have high switching costs.
- rowanseymour 1y ago
  Ok but that's really not the cost for a company that's been using tool X for years, accumulated some expertise in that, built their own tooling on top of it etc.
bckr 1y ago
Just try it. The hype is real. I stopped using pyenv, pyenv-virtualenv, poetry, and native pip because uv is just that sticky. Just install it and try running something using the —-with flag. That’s where I became intrigued.

adolph 1y ago

What is Astral's economic model? This is my primary hesitation to full adoption. Is Astral's future the same story as Anaconda?

steveklabnik 1y ago
https://news.ycombinator.com/item?id=44358216 https://news.ycombinator.com/item?id=44358216
- adolph 1y ago
  Ok, same story as Anaconda but they haven't gotten as far.

jdboyd 1y ago

What originally convinced me to try uv was the promise of faster container builds, and it certainly delivered on that. As someone who usually used platform pythons, despite advise against that, uv is now what got me to finally stop doing so.

kh_hk 1y ago

Just generate a requirements.txt with uv, ship that with docker, and then there's no need for all this dance

nrvn 1y ago

also a great guide for building production-ready containers using uv: https://hynek.me/articles/docker-uv/ https://hynek.me/articles/docker-uv/