It would be nice indeed if there was a good solution to multi-gigabyte conda directories. Conda has been reproducible in my experience with pinned dependencies in the environment YAML... slow to build, sure, but reproducible.

I'd argue bzip compression was a mistake for Conda. There was a time when I had Conda packages made for the CUDA libraries so conda could locally install the right version of CUDA for every project, but boy it took forever for Conda to unpack 100MB+ packages.

It seems they are using zstd now for .conda packages, eg, bzip is obsoleted, so that should be faster.

uv does it by caching versions of packages so they can be shared across projects/environments. So you still have to store those multi-gig directories but you don't have so much duplication. If conda could do something similar that would be great

> because new poetry releases would stall trying to resolve dependencies.

> uv is much faster than both of these tools

conda is also (in)famous for being slow at this, although the new mamba solver is much faster. What does uv do in order to resolve dependencies much faster?

> What does uv do in order to resolve dependencies much faster?

- Representing version numbers as single integer for fast comparison.

- Being implemented in rust rather than Python (compared to Poetry)

- Parallel downloads

- Caching individual files rather than zipped wheel, so installation is just hard-linking files, zero copy (on unix at least). Also makes it very storage efficient.

And electricity and running water and oh the inconvenience. How is this worse than getting a script file that expects you to install modules?

If I download python project from someone on the same network as me and they have it written in a different python version to me and a requirements.txt I need all those things anyway.

You can constrain Python version: https://peps.python.org/pep-0723/#:~:text=requires-python

I mean, if you use == constraints instead of >= you can avoid getting different versions, and if you’ve used it (or other things which combined have a superset of the requirements) you might have everything locally in your uv cache, too.

But, yes, python scripts with in-script dependencies plus uv to run them doesn't change dependency distribution, just streamlines use compared to manual setup of a venv per script.

You can specify python version requirements in the comment, as the standard describes

Sounds like a great use for a local LLM to strip ads from the output of the ad-infested LLM.

Well, heat capacity and thermal conductivity are not the same thing

because it's a much better experience than copy-pasting into a webapp

I'd like to try it, but enterprise only?

Surely there must be a way to do the joins in software, without doing it by hand, eg a SQL-like library? Pandas or equivalent?

Of course - but that is the best case scenario. You will need to support other kinds of queries as well, including writes, which is where it gets even more complicated. The guarantees provided by your RDBMS go away when you shard your database like this. Transactions are local to each database so writes to multiple cannot be a single transaction anymore.

Indeed. KYC has a purpose though -- prevention of fraud, money laundering, etc. Getting rid of KYC without a similarly-effective solution for those things seems unlikely. Ideas?

That’s not really true. Most financial crimes are big operations facilitated by banks. Criminals love KYC because that’s a chance to make their operations seem legit.

Here’s an idea, get rid of cryptocurrencies and the need for KYC basically vanishes.

Sure, there would be a black market for it, but that black market would be a lot smaller than the open market we have right now.

There’s plenty of legal ways of exchanging cryptocurrencies for real currencies, shutting those down would be a good start.

Things like this juice the anti-landlord sentiment: https://www.propublica.org/article/justice-department-sues-l...