the package is in scoop. scoop is in pip, pip is in poob. poob has it for you
@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
@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.