Earlier quoted context omitted.
I think you mean running out of acronyms. What is CS? 1. Computer Science 2. Customer Service 3. Clinical Services 4. Czech 5. Citrate synthase 6. Extension for C# files
It's Counter Strike of course
Common Sense
A year of uv: pros, cons, and should you migrate
331–340 of 401 posts
Re: A year of uv: pros, cons, and should you migrate
#332> You don't even need to know there is a venv, or what activation means.
> All those commands update the lock file automatically and transparently.... It's all taken care of.
When is the python community going to realize that simple is the opposite of easy? I don't see how hiding these aspects is desirable at all; I want to know how my programming tools work!
With all due respect to the author, I don't like the assumption that all programmers want magic tools that hide everything under the rug. Some programmers still prefer simplicity, ie understanding exactly what every part of the system does.
Nothing against uv, it seems like a fine tool. And I'm sure one could make a case for it on other technical merits. But choosing it specifically to avoid critical thinking is self-defeating.
Re: A year of uv: pros, cons, and should you migrate
#333Earlier quoted context omitted.
>> My use of python is somewhat recent. But the two languages that I have used a lot of - Java and JS - have interpreters that were heavily optimized over time. I wonder why that never happened with python and, instead, everyone continues to write their critical code in C/Rust. Improving Python performance has been a topic as far back as 2008 when I attended my first PyCon. A quick detour on Python 3 because there is…
A bit baffling, IMO, the focus on GIL over actual python performance, particularly when you had so many examples of language virtual machines improving performance in that era. So many lost opportunities.
They don't want to throw away the extensions and ecosystem. Let's say Jython, or some other modern implementation became the successor. All of the extensions need to be updated (frequently rewritten) to be compatible with and exploit the characteristics of that platform.
It was expected that extension maintainers would respond negatively to this. In many cases it presents a decision: do I port this to the new platform, or move away from Python completely? You have to remember, the impactful decisions leading us down this path were closer to 2008 than today when dropping Python or making it the second option to help people migrate, would have been viable for a lot of these extensions. There was also a lot of potential for people to follow a fork of the traditional CPython interpreter.
There were no great options because there are many variables to consider. Perf is only one of them. Pushing ahead only on perf is hard when it's unclear if it'll actually impact people in the way they think it will when they can't characterize their actual perf problem beyond "GIL bad".
Re: A year of uv: pros, cons, and should you migrate
#334Earlier quoted context omitted.
Naive take. https://gwern.net/holy-war counsels that, in fact, becoming the One True Package Manager for a very popular programming language is an extremely valuable thing to aim towards. This is even outside of the fact that `uv` is backed by a profit-seeking company (cf https://astral.sh/about ). I'm all for people choosing what works best for them, but I'm also staunchly pro-arguing over it.
> becoming the One True Package Manager for a very popular programming language is an extremely valuable thing For companies. Which is why when random people start acting like it’s important, you have to wonder why it’s important to them. For example, being a corporate shill. Or so deep in coolaid you can’t allow alternative opinions? Hm? It’s called an echo chamber.
>Which is why when random people start acting like it’s important, you have to wonder why it’s important to them.
I don't use uv because I don't currently trust that it will be maintained on the timescales I care about. I stick with pip and venv, because I expect they will still be around 10 years from now, because they have much deeper pools of interested people to draw contributors and maintainers from, because - wait for it - they are really popular. Your theory about random people being corporate shills for anything they keep an eye on the popularity of can be explained much more parsimoniously like that.
Re: A year of uv: pros, cons, and should you migrate
#335[deleted]
Re: A year of uv: pros, cons, and should you migrate
#336Earlier quoted context omitted.
My feeling sadly is because uv is the new thing, it hasn't had to handle anything but the common cases. This kinda gets a mention in the article, but is very much glossed over. There are still some sharp edges, and assumptions which aren't true in general (but are for the easy cases), and this only going to make things worse, because now there's a new set of issues people run into.
As an example of an edge case - you have Python dependencies that wrap C libs that come in x86-64 flavour and arm-64. Pipenv, when you create a lockfile, will only specify the architecture specific lib that your machine runs on. So if you're developing on an ARM Macbook, but deploying on an Ubuntu x86-64 box, the Pipenv lockfile will break. Whereas a Poetry lockfile will work fine. And I've not found any documentatio…
Yeah uv uses a platform independent resolution for its lockfiles supports features that Poetry does not, like
- Specifying a subset of platforms to resolve for
- Requiring wheel coverage for specific platforms
- Conflicting optional dependencies
https://docs.astral.sh/uv/concepts/resolution/#universal-res...
https://docs.astral.sh/uv/concepts/projects/config/#conflict...
Re: A year of uv: pros, cons, and should you migrate
#337> There are a lot of different ways to install Python, all with different default settings, and gotchas. With uv, there is now one more. https://xkcd.com/927/
Arnim Ronacher, author of rye (later uv) has very clearly highlighted that exact xkcd when he started working on rye. But he still decided that it was worth a try and as it turns out, rye/uv has become something that has a realistic chance of becoming the way to use python for most use-cases.
Cool point, thank you. I think his name is Armin.
Re: A year of uv: pros, cons, and should you migrate
#338I am a casual python user, and for that I love uv. Something I haven't quite figured out yet is integration with the pyright lsp - when I edit random projects in neovim, any imports have red squiggles. Does anyone know of a good way to resolve imports for the lsp via uv?
I start a shell with "uv run bash" and start neovim from there. I'm sure there's other ways but it's a quick fix and doesn't involve mucking around with neovim config.
Re: A year of uv: pros, cons, and should you migrate
#339Earlier quoted context omitted.
Pinning deps is a good thing, but it won't necessarily solve the issue of transitive dependencies (ie: the dependencies of requests itself for example), which will not be pinned themselves, given you don't have a lock file. To be clear, a lock file is strictly the better option—but for single file scripts it's a bit overkill.
1 file, 2 files, N files, why does it matter how many files? Use a lock file if you want transitive dependencies pinned. I can't think of any other language where "I want my script to use dependencies from the Internet, pinned to precise versions" is a thing.
I think it's a general principle across all of software engineering that, when given the choice, fewer disparate locations in the codebase need to have correlated changes.
Documentation is hard enough, and that's often right there at exactly the same location.
Re: A year of uv: pros, cons, and should you migrate
#340Like so many other articles that make some offhand remarks about conda, this article raves about a bunch of "new" features that conda has had for years. > Being independent from Python bootstrapping Yep, conda. > Being capable of installing and running Python in one unified congruent way across all situations and platforms. Yep, conda. > Having a very strong dependency resolver. Yep, conda (or mamba). The main thing…
Thanks for bringing up conda. We're definitely trying to paint this vision as well with `pixi` ( https://pixi.sh ) - which is a modern package manager, written in Rust, but using the Conda ecosystem under the hood. It follows more of a project based approach, comes with lockfiles and a lightweight task system. But we're building it up for much bigger tasks as well (`pixi build` will be a bit like Bazel for cross-plat…
I just want to give a hearty thank you for pixi. It's been an absolute godsend for us. I can't express how much of a headache it was to deal with conda environments with student coursework and research projects in ML, especially when they leave and another student builds upon their work. There was no telling if the environment.yml in a student's repo was actually up to date or not, and most often didn't include actual version constraints for dependencies. We also provide an HPC cluster for students, which brings along its own set of headaches.
Now, I just give students a pixi.toml and pixi.lock, and a few commands in the README to get them started. It'll even prevent students from running their projects, adding packages, or installing environments when working on our cluster unless they're on a node with GPUs. My inbox used to be flooded with questions from students asking why packages weren't installing or why their code was failing with errors about CUDA, and more often than not, it was because they didn't allocate any GPUs to their HPC job.
And, as an added bonus, it lets me install tools that I use often with the global install command without needing to inundate our HPC IT group with requests.
So, once again, thank you