Also for me. 8b and 32b are Qwen based, 7b and 70b are Llama based. Trying the same queries against qwen2.5:7b produces markedly different results (sanitized vs. blocked entirely), however, so there must be some interplay between the foundation model and distillation accounting for the difference.
The guy doesn't know what he's talking about as pip certainly has dependency resolution. Rather get your python or tech info from a non-flame-war infested thread full of anti-pip and anti-python folk.
I am not a python developer, but sometimes I use python projects. This puts me in a position where I need to get stuff working while knowing almost nothing about how python package management works.
Also I don’t recognise errors and I don’t know which python versions generally work well with what.
I’ve had it happen so often with pip that I’d have something setup just fine. Let’s say some stable diffusion ui. Then some other month I want to experiment with something like airbyte. Can’t get it working at all. Then some days later I think, let’s generate an image. Only to find out that with pip installing all sorts of stuff for airbyte, I’ve messed up my stable diffusion install somehow.
Uv clicked right away for me and I don’t have any of these issues.
Was I using pip and asdf incorrectly before? Probably. Was it worth learning how to do it properly in the previous way? Nope. So uv is really great for me.
This is not just a pip problem. I had the problem with anaconda a few years ago where upgrading the built in editor (spyder?) pulled versions of packages which broke my ML code, or made dependencies impossible to reconsile. It was a mess, wasting hours of time. Since then I use one pip venv for each project and just never update dependencies.
Spyder isn't built-in; IDLE comes with Python (unless you get it via Debian, at least), but is not separately upgradable (as the underlying `idlelib` is part of the standard library).
If upgrading Spyder broke your environment, that's presumably because you were using the same environment that Spyder itself was in. (Spyder is also implemented in Python, as the name suggests.) However, IDEs for Python also like to try to do environment management for you (which may conflict with other tools you want to use specifically for the purpose). That's one of the reasons I just edit my code in Vim.
If updating dependencies breaks your code, it's ultimately the fault of the dependency (and their maintainers will in turn blame you for not paying attention to their deprecation warnings).
Thanks. I understand this a lot more now that I've learned about venvs, and I'm between VScode and emacs for editing. No longer would I install a editor which depends on the same environment as the code I want to run.
As for Spyder, it is included in the default Windows install of Anaconda (and linked to by the default Anaconda Navigator). As a new user doing package management via the GUI, it was not clear at all that Spyder was sharing dependencies with my project until things started breaking.
Anaconda was also half-baked in other ways: it broke if the Windows username contains UTF-8 characters, so I ended up creating a new Windows user just for that ML work. PITA.
You're all over the thread defending the standard python tools, which is fine, it works for you. But the amount of times you've had to write that something is natively supported already or people is just using it wrong speaks volumes about why people prefer uv: it just works without having to learn loads of stuff.
My life got a lot easier since I adopted the habit of making a shell script, using buildah and podman, that wrapped every python, rust, or golang project I wanted to dabble with.
It's so simple!
Create a image with the dependencies, then `podman run` it.
You can still change the ending. It is your article and right now quite a few people will have read it, but if you keep it live for years many more will probably get to read it and there is no reason why you should keep some first version of it online if you think it should’ve been different.
You wouldn’t leave a v1 of an app online just because it is first
Let me start by saying that I am an experienced developer, so I doubt I'd unlearn syntax any time soon. Also the way I write with AI still has me writing a lot of the code. I use Cursor.
The way it helps me is in refactoring it sees 1 example and will apply the same pattern in the following 10 places in the code and it will suggest tailwind classes for colors, etc pretty accurately. That is in Rails.
Using AI has let me write pretty complicated Python applications, production ready, in an hour per application, even though I know no Python.
The other day in minutes I produced a bash script that let me loop through all sub-directories of a given directory, find all mp4 files, check with ffprobe if the audio stream within was flac or m4a, saved all metadata from those files into JSON using a python script it wrote and then ran ffmpeg to convert the mp4 to either flac or m4a and then reapply the metadata, if the filesize difference was within 800kb it would auto-delete the mp4.
All that in a few minutes. Obviously I could've done that either in Ruby or Bash, but this was way way way faster and it would help me debug things super quickly too.
I sometimes disable the AI suggestions when I am writing some novel code, but overall AI has released me from writing the 'boring code' and it allows me to leverage libraries and tools from different languages if the use case requires it. Super powerful!
I do understand I have the advantage of experience without AI so I am able to steer the AI towards solutions that my experience tells me are useful and I can judge the produced code pretty well. I have no idea how this all feels to a junior developer and whether it does more harm than good to their learning experience.
I've not used it myself, but I am going to rewrite one of my projects that I only use locally from postgres to litestack. The benchmarks are incredible!
Very good question, I don't know. Ideally you'd stick with the most vanilla stack, being solid queue, etc. However after trying solid queue in my production environment with Postgres I was left very disappointed at the reliability and speed. This could've been some misconfiguration on my part though.
Another thing that I noticed is that if you compare litestack's benchmarks to solid_cable (for example) litestack claims to outperform redis whereas the argument for solid_queue is that it is slower, but worth the simplicity of 'just using the database': https://github.com/rails/solid_cable?tab=readme-ov-file
All in all I would prefer 'the standard' solution, but I am interested in experimenting with litestack. After all that is what side projects are perfect for.
What they meant was https://github.com/oldmoe/litestack which has a lot of things built on top of sqlite, like job queue and caches. Rails 8 now comes with most of them out of the box.
My SaaS ran on litestack until rails 8 came out, then I switched without problems.
