There's so many more! 1. `uvx --from git+ https://github.com/httpie/cli httpie` 2. https://simonwillison.net/2024/Aug/21/usrbinenv-uv-run/ uv in a shebang
Super neat re Willison article.. would something like this work under powershell though?!
Uv's killer feature is making ad-hoc environments easy
141–150 of 428 posts
Re: Uv's killer feature is making ad-hoc environments easy
#142Earlier quoted context omitted.
Pip only has requirements.txt and doesn't have lockfiles, so you can't guarantee that the bugs you're seeing on your system are the same as the bugs on your production system.
I’ve always worked around that by having a requirements.base.txt and a requirements.txt for the locked versions. Obviously pip doesn’t do that for you but it’s not hard to manage yourself. Having said that, I’m going to give uv a shot because I hear so many good things about it.
With pip the best practice is to have a requirements.txt with direct requirements (strictly or loosely pinned), and a separate constraints.txt file [1] with strictly pinned versions of all direct- and sub-dependencies (basically the output of `pip freeze`). The latter works like a lock file.
[1] https://pip.pypa.io/en/stable/user_guide/#constraints-files
Re: Uv's killer feature is making ad-hoc environments easy
#143Small misorder in the „right route” - you should first activate the virtual environment just created and then install pandas.
Re: Uv's killer feature is making ad-hoc environments easy
#144As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.
Half the time something breaks in a javascript repo or project, every single damn javascript expert in the team/company tells me to troubleshoot using the below sequence, as if throwing spaghetti on a wall with no idea what's wrong. Run npm install Delete node_modules and wait 30minutes because it takes forever to delete 500MB worth of 2 million files. Do an npm install again (or yarn install or that third one that p…
What kind of amateurs are you working with? I’m not a Node.js dev and even I know about npm ci command.
Re: Uv's killer feature is making ad-hoc environments easy
#145Re: Uv's killer feature is making ad-hoc environments easy
#146As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.
I've only recently started with uv, but this is one thing it seems to solve nicely. I've tried to get into the mindset of only using uv for python stuff - and hence I haven't installed python using homebrew, only uv. You basically need to just remember to never call python directly. Instead use uv run and uv pip install. That ensures you're always using the uv installed python and/or a venv. Python based tools where…
> Python based tools where you may want a global install (say ruff) can be installed using uv tool
uv itself is the only Python tool I install globally now, and it's a self-contained binary that doesn't rely on Python. ruff is also self-contained, but I install tools like ruff (and Python itself) into each project's virtual environment using uv. This has nice benefits. For example, automated tests that include linting with ruff do not suddenly fail because the system-wide ruff was updated to a version that changes rules (or different versions are on different machines). Version pinning gets applied to tooling just as it does to packages. I can then upgrade tools when I know it's a good time to deal with potentially breaking changes. And one project doesn't hold back the rest. Once things are working, they work on all machines that use the same project repo.
If I want to use Python based tools outside of projects, I now do little shell scripts. For example, my /usr/local/bin/wormhole looks like this:
#!/bin/sh
uvx \
--quiet \
--prerelease disallow \
--python-preference only-managed \
--from magic-wormhole \
wormhole "$@"Re: Uv's killer feature is making ad-hoc environments easy
#147Earlier quoted context omitted.
Well, for one you can't actually package or add a local requirement (for example , a vendored package) to the usual pip requirements.txt (or with pyproject.toml, or any other standard way) afaik. I saw a discourse reply that cited some sort of possible security issue but that was basically it and that means that the only way to get that functionality is to not use pip. It's really not a lot of major stuff, just a lot…
Sure you can. It's in their example for how to use requirements.txt: https://pip.pypa.io/en/stable/reference/requirements-file-fo... Maybe there's some concrete example you have in mind though?
I don't think so, though maybe I didn't explain myself correctly. You can link to a relative package wheel I think, but not to a package repo. So if you have a repo, with your main package in ./src, and you vendor or need a package from another subfolder (let's say ./vendored/freetype) , you can't actually do it in a way that won't break the moment you share your package. You can't put ./vendored/freetype in your requirements.txt, it just fails.
That means you either need to use pypi or do an extremely messy hack that involves adding the vendored package as a sub package to your main source, and then do some importlib black magic to make sure that everything uses said package.
https://github.com/pypa/pip/issues/6658
https://discuss.python.org/t/what-is-the-correct-interpretat...
Re: Uv's killer feature is making ad-hoc environments easy
#148I really like uv, and it's the first package manager for a while where I haven't felt like it's a minor improvement on what I'm using but ultimately something better will come out a year or two later. I'd love if we standardized on it as a community as the de facto default, especially for new folks coming in. I personally now recommend it to nearly everyone, instead of the "welllll I use poetry but pyenv works or you…
This: > I haven't felt like it's a minor improvement on what I'm using means that this: > I'd love if we standardized on it as a community as the de facto default …probably shouldn’t happen. The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way. It would be like replacing the python repl with the current version of ipython. I’d say the same thing, that it is…
> The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way.
This to me is unachievable. Perfection is impossible. On the the way there if the community and developers coalesced around a single tool then maybe we can start heading down the road to perfectionism.
Re: Uv's killer feature is making ad-hoc environments easy
#149As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.
Half the time something breaks in a javascript repo or project, every single damn javascript expert in the team/company tells me to troubleshoot using the below sequence, as if throwing spaghetti on a wall with no idea what's wrong. Run npm install Delete node_modules and wait 30minutes because it takes forever to delete 500MB worth of 2 million files. Do an npm install again (or yarn install or that third one that p…
Sounds like a tale from a decade ago, people now use things like pnpm and tsx.
Re: Uv's killer feature is making ad-hoc environments easy
#150Earlier quoted context omitted.
Ugh, I hate writing this but that's where docker and microservices comes to the rescue. It's a pain in the butt and inefficient to run but if you don't care about the overhead (and if you do care, why are you still using Python?), it works.
My experience was that docker was a tool data scientists would use to speedrun the process of finding broken Pythons. For instance we'd inexplicably find a Python had Hungarian as the default charset, etc. The formula was - Docker - Discipline = Chaos Docker - Discipline = Chaos Docker + Discipline = Order but - Docker + Discipline = Order If you can write a Dockerfile to install something you can write a bash script…
Unfortunately sometimes you get to host things not written by you, or which exist for a long time and thus there's a lot of history involved that prevents nice and tidy.
My first production use of kubernetes started out because we put in the entirety of what we had to migrate to new hosting into spreadsheet, with columns for various parts of stack used by the websites, and figured we would go insane trying to pack it up - or we would lose the contract because we would be as expensive as the last company.
Could we package it nicely without docker? Yes, but the effort to package it in docker was smaller than packaging it in a way where it wouldn't conflict on a single host, because the simple script becomes way harder when you need to handle multiple versions of the same package, something that most distro do not support at all (these days I think we could have done it with NixOS, but that's a different kettle of deranged fishes)
And then the complexity of managing the stack was quickly made easier by turning each site into separate artifact (docker container) handled by k8s manifests (especially when it came to dealing with about 1000 domains across those apps).
So, theoretically discipline is enough, practical world is much dirtier though.