That’s slippery slope. If you reason about performance in absolute terms, nobody will ever get things done. The reason we have electron apps is very much not because people are not shaving off 1.5MB off their binaries. This request to not use uv-build because of 1.5MB is just insane and out of touch for normal consumer hardware, and it only makes sense in the context of SPARC.
uv uses hardlinks, you’ll only need more space if you need different versions of uv-build
1.5MiB wasn’t much 20 years ago, even with a rampocalypse that’s not changing soon.
It’s a huge dependency (as of 0.13.0, its wheels are between 1.2 MiB and 1.5 MiB, depending on the platform)
🤣
hatch has hardcoded awareness of Git and Mercurial and specifically searches for project-level .gitignore and .hgignore to read those files directly. But it doesn’t handle user-level or system-level config, so anything you have ignored from config outside of your project, like .env in my example, will not be ignored by hatch, and will wind up in your sdist.
ah that probably explains why I didn’t have this problem, same reason why I don’t like global gitignores
good tooling, though pylance can be mostly replaced by pyrefly or ty today - both of which are much faster and don’t enter “analyzing files” loop like I’d always have with pylance, or the CPU being pegged at 100%
I have no idea why you would assume “bloat” is the result of a linear combination of reasonably sized packages when - whether you look at package size, lines of code, or file sizes on disk - you rarely find uniform distributions in real life.
It’s a lot more likely your “bloat” comes from a handful of packages or dependencies than tens of reasonably sized ones.