2,528 karma · joined September 26, 2014
(It's the training, not the inference, that's the biggest energy usage.)
Could you share some of your prompts or CLAUDE.md? I'm still learning what works.
The problem is there's no metadata for which versions fix security bugs, and therefore which previous versions are now insecure.
uv lock --exclude-newer $(date --iso -d "24 hours ago")
uv is considering a native relative date:Technically for fonts, there’s no API for listing installed fonts, so trackers have to check each font by name. Likely they won’t be checking super obscure font names.
That method might help for other signals though.
The site doesn't even need to have valuable content. Any content at all.
The Machine-Learning world, especially "Google Brain" research team figured out that NumPy was an awesome piece of software for dealing with large arrays of numbers and matrix multiplication. They built "TensorFlow" on top of it around 2015 which became very popular. Facebook followed suit and released PyTorch in 2016.
IPython/Jupiter notebooks (for Julia, Python and R) from 2015 were another factor, also adopted by the AI/ML community.
The alternative data-science languages at the time were Mathematica, MATLAB, SAS, Fortran, Julia, R, etc, but Python probably won because it was general purpose and open source.
I suspect Python would not have survived the 2/3 split very well if it wasn't for AI/ML adopting Python as its main language.
> when the tooling was so inferior
Since 2012, Conda/Anaconda has been the go-to installer in the SciPy/NumPy world which also solves a lot of problems that uv solves.
Yes, Poetry has had lock files for years, and pyenv has been able to manage installations, but uv is "an incredibly powerful simplification" that makes it easy to do everything really well with just one tool.
`uv run` will also sync the environment to be sure it exists and meets the correct specifications.
But yes, it's optional. You can also just do `uv sync` to sync the environment and then activate it like normal.
Or use `uv venv`, `uv pip` commands and just take the speed advantage.
If you haven't spent 5 minutes trying it out, you don't know what you're missing.
If you're worried about getting addicted like everyone else, I could see that as a valid reason to never try it in the first place.
It’s hard to demonstrate the speed difference in a pitch deck.
For me package installation is way, way faster with uv, and I appreciate not needing to activate the virtual environment.
You can `pip install uv` or manually download and extract the right uv-*.tar.gz file from github: https://github.com/astral-sh/uv/releases
The fact that it's a binary, not written in python, also simplifies bootstrapping. So you don't need python+dependencies installed in order to install your python+dependencies.
uv is probably much more of a game changer for beginner python users who just need to install stuff and don't need to lint. So it's a bigger deal for the broader python ecosystem.
The `uv run` command is an optional shortcut for avoiding needing to activate the virtual environment. I personally don't like the whole "needing to activate an environment" before I can run commands "natively", so I like `uv run`. (Actually for the last 10 years I've had my `./manage.py` auto-set up the virtual environment for me.)
The `uv add` / `uv lock` / `uv sync` commands are still useful without `uv run`.
You may have a library that's been globally installed, and you have multiple projects that rely on it. One day you may need to upgrade the library for use in one project, but there are backward incompatibile changes in the upgrade, so now all of your other projects break when you upgrade the global library.
In general, when projects are used by multiple people across multiple computers, it's best to have the specific dependencies and versions specified in the project itself so that everyone using that project is using the exact same version of each dependency.
For recreational projects it's not as big of a deal. It's just harder to do a recreation of your environment.
In principle, you can ‘activate’ this new virtual environment like any typical virtual environment that you may have seen in other tools, but the most ‘uv-onic’ way to use uv is simply to prepend any command with uv run. This command automatically picks up the correct virtual environment for you and runs your command with it. For instance, to run a script — instead of
source .venv/bin/activate
python myscript.py
you can just do uv run myscript.pyIt's moving pretty quick.
> Do they have good influence on what python's main ecosystem is moving to?
Yes, they're an early adaptor/implementer of the recent pyproject.toml standards.
Have you tried uv?
> Reminds me of that competing standards xkcd.
Yes, for years I've sat on the sidelines avoiding the fragmented Poetry, ppyenv, pipenv, pipx, pip-tools/pip-compile, rye, etc, but uv does now finally seem to be the all-in-one solution that seems to be succeeding where other tools have failed.
You can go from no virtual environment, and just "uv run myfile.py" and it does everything that's needed, nearly instantly.