35
A plea not to use uv-build for Python (blogs.gentoo.org)
submitted 3 days ago by to c/python@programming.dev
27 comments fedilink hide all child comments
 

@mgorny@treehouse.systems:

After seeing yet another dozen packages lose keywords on Gentoo because of a single key dependency switching to uv-build, I would like to plea on behalf of Gentoo users: please don’t use uv-build as a build backend.

Just to be clear, this is not about uv itself or any other Astral tools; these are good tools with a nice and responsive upstream. The uv-build backend is one thing we have to disagree on. I’m not saying it’s bad; I’m saying that its benefits don’t outweigh the drawbacks.

you are viewing a single comment's thread
view the rest of the comments
[–] [S] 13 points 3 days ago (15 children)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 15 child comments
    •
  • [–] 12 points 3 days ago (14 children)

    1.5MiB wasn't much 20 years ago, even with a rampocalypse that's not changing soon.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 14 child comments
    •
  • [–] 12 points 3 days ago* (9 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 10 points 3 days ago (6 children)

    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".

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 0 points 3 days ago* (last edited 3 days ago) (5 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 2 days ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 0 points 3 days ago* (3 children)

    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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 3 days ago* (last edited 3 days ago) (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 3 days ago* (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 2 days ago* (last edited 2 days ago)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 3 days ago

    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".

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 3 days ago (3 children)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •