TIL: uv —script
I've known for a while that uv can run Python scripts that declare inline dependencies.
I learned today that you can also use uv to manage those dependencies.
I've known for a while that uv can run Python scripts that declare inline dependencies.
I learned today that you can also use uv to manage those dependencies.
(via epistasis on HN)
Semantic versioning is difficult. Not everyone has the same idea of what “breaking change” means, and depending on your language and tooling “breaking” changes can sneak in despite your best efforts.
One possible mitigation is to record when you resolved your dependencies and ignore anything published after that date. It's crude, and relies on package dependencies not monkeying with stuff that's already been published, but it's easy to understand and you can do it with uv.
It's documented here.
Put a date in your pyproject.toml file and subsequent invocations of uv will ignore anything published after the cutoff:
[tool.uv]
exclude-newer = "2023-10-16T00:00:00Z"
You can also use it in the “inline metadata” format for scripting! From the uv docs:
# /// script
# dependencies = [
# "requests",
# ]
# [tool.uv]
# exclude-newer = "2023-10-16T00:00:00Z"
# ///
import requests
print(requests.__version__)
This use case seems particularly valuable: if I write a quick script I probably care more about it not breaking than I care about it getting updated dependencies. It's nice that uv offers a way to keep code running rather than forcing me to update it or throw it out.
#python #llm #embeddings #release #simonwillison
I just released version 0.1 of a plugin for Simon Willison's llm called llm-questioncache. It lets you send questions to your default LLM with a system prompt that elicits short, to-the-point answers. It also maintains a cache of answers locally so that you only have to hit the LLM once for each bit of esoteric knowledge.
#til #django #djangorestramework #python
On a recent project I found myself needing one classic form-and-template style page in an otherwise API-driven project. I could, of course, [just do it] with a regular view function, but I had a bunch of authentication and suchlike set up for DRF APIViews.
Turns out it's actually pretty easy to make an APIView kick it oldschool!
A useful question for understanding software tools is to peel back a layer of abstraction and ask what the thing underneath is. For example:
Knowing this sort of thing is useful when the abstractions break (e.g. when you open a text file with the wrong encoding) or when thinking about the fundamental contours of a system's possibility space. For example, if you know that programs can be configured with environment variables and CLI flags, knowing that the Python interpreter is a program means you know where to start looking if you need to configure it.
While there are many, many articles on the internet explaining how and why to use them, there's less information about what a Python virtual environment (or “virtualenv”) is. Luckily for us, it ends up not being very difficult to investigate.
When I'm doing data analysis or building applications with Python and I have to give entities a unique ID, I like to use random UUIDs instead of sequential numbers. Sequential numbers include information about the order and total number of data, but I want my IDs to be just a unique identifier, nothing more.