Wow! Wish the majority of packages i encounter has this problem; too many releases.

That sounds really nice. Actively maintained packages for a change.

The additional work doesn't go away when you add support for higher end systems that most can't afford to use, let alone want to.

This premise, that progress requires abandon, is taken for granted because of commercial interests.

If people were as interesting in maintaining their projects as they were in riding the new wave, there'd really be no issue.

There are other good reasons to not support older systems, beyond commercial interests.

Every additional system that is supported comes with a cost of time and effort. When the system is rare (SPARC), continuing to support it doesnt make sense, especially when that time and effort can be put towards maintaining other more common systems.

Also, supporting older systems can hold back new technology. Most Linux distros are built with an ancient minimum x86 version, which means that many of the modern CPUs aren't being optimised for. Its good for compatibility, but it is holding back new systems. Every Ubuntu/fedora/etc release their respective steering committees will usually have a discussion about dropping older CPU support. Gentoo at least has a solution for that, because everything is recompiled for the specific system.

IMO, if their system is so resource constrained that 1.5mb is too much to bear, they're well into the "holding everyone else back" territory, 128GB SSDs are 40AUD, which is two big Mac meals. And if they are on SPARC, thats well into the rarity territory, the last SPARC CPU was released in 2017, and they were never common for consumer PCs.

There is a difference between "planned obsolecence" and actual obsolecence, and this case feels like the later.

Believe it or not, my point was exactly what I said it was; without subtext. Fwiw, the reason I made it is that not supporting older systems is something peoole tend to do to appease the commercial interests of their employers, and the broader and higher classes of employers. Imo, it sounds more like you told your boss that their strategy didn't align with their own interests than what you said to the quote in question.

Somewhat of a side discussion, but these aren't the only issues you can have when using uv-build.

While it's stable now, it expects certain directory layouts and can only be used on pure Python projects. If you need anything else, you are better off using hatchling anyway, which used to be the default even for uv.

This is also why some of your old uv-based projects might build fine and the same code won't build in a modern uv project; they switched the default.

Here's a thing directly from the authors:

While the backend supports a number of options for configuring your project structure, when build scripts or a more flexible project layout are required, consider using the hatchling build backend instead.

Source

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.

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.

If multiple people are continuing to miss a point you think you've made, perhaps consider if you've properly communicated your point before moving directly to pretentiousness.

The best orientation for capturing sound the ear canal is to keep the ear straight from lobe to tip. (across the pitch axis at least, that's the rotation that enables nodding).

As you pitch forward or backward you start to capture less and less of the sound across the plane the brain expects sound to be coming from.

If you have your head pitched backwards by~ 70-90 degrees (as if you were looking directly down your nose at someone in front of you) you will struggle to hear/understand what is being said, especially from directly in front of you.

Perhaps there's a metaphor in there somewhere, maybe even tree related, as that seems to be the theme.

Good luck with your imaginary forest.

You are right. Everything stated, (while missing the point), was correct.

Arizona is a state. Factually correct. Does it belong here? It must. It's factually correct.

Here is a point for you:

.

Be sure to miss it 😉

You're still focused on the tree, consider the forest someday.

Good luck in life my friend.

That's a particularly pretentious response to a reply that was subjectively factually correct.

Though expect it's difficult to hear what's actually being said with your head tilted so far back.

edit : I'm not the person to which you were responding, in case that wasn't clear

I absolutely would say that to a billionaire, because they aren't paying me.

My boss, have said it a number of times. I've almost verbatim told them that their use case doesn't line up with our broader user bases' use case, and that I wasn't going to support it. Part of a healthy working relationship is being able to push back.

Ignoring my specific case though, what is your point? That people with power shouldn't ever face push back? Surely that's not your point?

You can't expect the rest of the world to make their lives harder to support your niche.

I bet you wouldn't say that shit to your boss, or a billionaire

It does seem hypocritical for Gentoo to complain about wasted time building things from source over and over because of another project's policies when the whole point of Gentoo is building things from source over and over.

Also, assuming any project that doesn't pin a specific version of a dependency requires the latest possible version seems backwards, as that's typically how things indicate that they're independent of any particular version.

and different versions of the dependencies in different projects

I mostly agree, but there is a tradeoff here between effort and resource usage

Do you spend the extra x months dev time to go from 800Mb to 200Mb?

how about another x months to go from 200MB to 100MB?

100MB -> 80Mb? 80Mb -> 67Mb ?

and that's only memory footprint, not performance, test coverage, infrastructure etc.

We've swung way in to the "800Mb binary ?, meh, they all have RAM to spare" (looking at you specifically fucking electron shells) and i fully agree we should be way more on the side of resource usage optimisation.

Optimising for deadlines and effort costs is also a consideration, if we don't acknowledge and address that as part of the conversation, it'll be seen as gold-plating or "perfect is the enemy of good".

You're right, 1.5MiB isn't a lot. No one is saying it is. The larger point that you are missing is:

bloat_MiB = 0
for (( discussion=1;discussion<101;discussion++ ));do
echo "i noticed the dependencies grew by 1.5MiB, should we address that?"
echo "1.5MiB isn't a lot, let's not think about it."
bloat += 1.5
done
echo "where did this bloat come from?"

You're focused on 1.5MiB and missing the larger discussion.

My question is, are you engaging with the discussion or are you attempting to be right? Yes. One instance of 1.5MiB isn't bloat, but it is a symptom of bloat.

Users here are discussing a mindset of ignoring optimization, and many responses are missing the forest (bloat root cause) to focus on the trees (the 1.5MiB example used for demonstration purposes only). Ironically embodying the very mindset which contributes to the bloat root cause. It's amusing, in a way.

There is a valid discussion to be had for software bloat, but 1.5mb isnt huge by any measure. Plenty of binaries can and do exceed that without being "poorly coded".

Kinda bummed out that we won't see the perfect πthon: 3.14.15

This line of thinking is why binaries today are like 800 MB. If you can cut cruft as you go during development you shouldn’t have to go back and say “it’s only 1.5 MB”. You should’ve been in the habit of writing DRY, clean code and not importing libraries that do nothing but add bloat.

I’m sorry but I’m sick and tired of this attitude where I work (web development). We are blowing thousands/millions of dollars per year on resources because people no longer believe in optimizing anything. I’ve lost count where I’ve pushed back and said “we need to figure out how to do this with less memory” rather than simply handing shit more and more and more.

It might seem nitpicky as fuck at first, but if you start designing with good processes these wins become more automatic.

uv uses hardlinks, you'll only need more space if you need different versions of uv-build

Multiple this by the number of package dependencies which with virtual environments easily become high thousands.

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)

🤣

What world are they living in that 1.5MiB is huge?

That depends. Am I buying the SSD last year, or today?

The RAMpocalypse is going to make “this doesn't run on a low-powered low-capacity device” a much more relevant issue.