I love when I look up a project and it's like "okay to build this, install poetry" and I click poetry and it goes "poetry should be installed with pipx" and I click pipx and it says "on windows, you should install pipx with scoop" so I click scoop and then my brain melts out my ears because this is too many layers deep

the package is in scoop. scoop is in pip, pip is in poob. poob has it for you


#i-have-been-told-that-too-many-times-about-the-name-wafrn #still #poob-has-it-for-you
@foone my experience of typescript was much the same. Using yarn to install an npm manager to install npm to install typescript as a dependency of my proje--why do I need a project, I just want a got-dang compiler!
@foone
Never looked into the Windows package manager scene, anything cool and/or funny about them?

Linux-style package managers are quite nifty: but by the time I put Xubuntu on my laptop the desire to actively use modern Windows steadily evaporated.
(would still happily use 95, 2000 or 7 on a secondary machine)
(maybe NT 3.51 if I knew anything about backporting software)
(more of a Debian and derivatives guy these days)
@foone Every problem in CS can be solved by adding a layer, except for "too many layers"
@BoredomFestival @foone ah then you just need an encapsulating layer that contains all the other layers
@jackeric @foone :galaxybrain:
@BoredomFestival @foone a single layer that encompasses the other 14 layers' use cases
@jackeric @foone the CS gods will look askance at such a cheap trick and you will inevitably reap the whirlwind
@jackeric @BoredomFestival @foone there are now 15 layers that you have to track
@foone typical windows developer experience tbh

@lunareclipse @foone language-specific package management and various flavors of dockerization have brought it to other platforms too

it's a rare treat to see a project whose build instructions are just "here's a list of lib*-dev dependencies to install via your distro, then run cmake"

@foone love how even with interpreted languages the build process is usually the most tedious and difficult bit

made a single-file python script to do a thing. the partially implemented api wrapper is generically useful so I pulled it out into its own project to work on separately. can I remember offhand how to configure that project, or to convert my standalone script into a project with a pyproject.toml folder and unit tests that correctly references the WIP wrapper in the next folder over on my PC? can I heck

@foone People should use more Javascript instead of python #teamjavascript
@foone sorry babe I can't go, I have to install another package manager for my package manager's package manager and it won't compile without another package manager that hasn't gotten an update since 2017
@foone I love Python, but this is why I hate Python. ​
@foone I went through exactly those steps and went “fuck that” to scoop and just installed pipx globally on my python path.
@foone i'd drop it on first windows mention, it's so ass i'd rather explode than build anything there
@foone don't forget the step where pip refuses to run unless you have an venv. https://peps.python.org/pep-0668/
@th @foone this is squarely on distros
@foone Python package management is basically a Superfund site at this point. On the plus side, I have not hated using uv for Python dependency management recently!
@foone aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
@foone A similar feeling to how I feel about many Java build systems.

Turns out the way many Guix packages do it is to just figure out what needs to be built and how, and then completely bypass the nonsense build systems (some of them seemingly don't even support any method of offline operation, they have achieved total conflation of dependency resolution language package manager (ewww) and build system).
@lispi314 @foone Guix is a wonderful island of respite from the M×N package managers problem
@ryanprior @foone I would imagine other distro package managers do it similarly because I really cannot see the labor being tractable any other way.
@lispi314 @foone I'm working on something in this space 
@ryanprior @foone JavaScript is one of those cases that has it worse than Java, because it took the language so long to have some standard manner of dealing with imports & such that the Java-like approach isn't actually usable with the majority of it.
@lispi314 @foone JavaScript, golang and rust are all victims of language package managers that work with too little friction, in my view. Python and Java have more humane package commons because the package managers are obnoxious to work with, so people don't want to pull in 5000 transitive package drops to do something routine

@ryanprior @foone In my opinion the problem starts at the conflation of dependency resolution and build systems.

The introduction of build systems with resolution builtin promptly reduces the friction of introducing spurious, dangerous and unnecessary dependencies to the point that short of already knowing better most will simply not have the time to think about it (Golang is big on this, but this is an issue I've noticed in a lot of IDE-centric languages).

(It also de-incentivizes proper packaging so it promptly gets left to the wayside, compounding the issue.)

Most original Java build systems had no such resolution at all and it shows in the language design (although this could be a chicken & egg thing and I'm reversing causality).

Python I think was coasting on inertia of other languages doing it right, since I think it did technically have resolution built-in from the start.

@foone I actually thought scoop was a joke name you made up, until I googled it...

@foone I have no idea how to install windows anymore. Can that part be skipped?

#pooptoot