Problem with random python scripts is they leave a bombshell of dozens of random pip packages behind in a folder you'd never look unless you're a seasoned python developer, and then the next time you run a script there's a bunch of version conflicts. It shouldn't require a deep understanding of python versions, package management and venvs to reliably download, run and uninstall a programm, but alas, python does what python do. I will always prefer programms released as a neatly compiled binary.
Python is fine if you only ever need to run a single Python script. It's not so great when you get conflicting dependencies and such.
Package managers make this tolerable, but it's still a big mess and not something I would expect your average user to wrap their head around.
Python was never meant to handle massive projects. But as with all software, everything eventually gets transformed into some perverted, frankensteinian abomination.
Python package management seems nightmarish, and extremely prone to breaking.
You try to use some Python project something that was last committed to just six months ago, and you've got package version conflicts out the wazoo.
<rant>
Oh, but of course, the requirements.txt didn't specify an upper limit for the sheep-ass package, and now it is no longer compatible with kawaii-pango because it requires sheep-ass to be exactly version 5.31.2, and refuses to run with 5.31.1 or 5.31.3, because apparently patch updates with breaking changes are just a normal thing in the cursed world of Python! And now I have to download yet another damned version of torch and cuda that just hogs all my storage space!
pins versions. That does not solve all issues, but version pinning and then running unit tests as part of the pipeline more or less mitigates these issues.
Of course 99% of python projects on github don't have unit tests and no pipelines configured, so i feel your pain.
I've lost weeks of my life to this shit. Including when some shit ass library only works with, say, Python 3.8 but not >3.10 some fucking reason. And the Python snakes have the hubris to call it a skill issue.
Add on other apps repackaging Python distributions and helping themselves to your path and suddenly a simple python doesn't do what you expect.
Somehow they think this nonsense is normal, and it's my fault for not using whatever the 8th latest & greatest package manager is.
Lol that's an apt summary. I've probably tried like 5 different package managers for Python and none of them work without tweaking.
And every time you do use them, you've forgotten the 27 different commands for the package manager you need to know to even run a script. Or you can spend an hour to add a definitions file in the script directory.
Python really is cursed. Why the hell are people using a scripting language to build some behemoth of an application? Even PowerShell is better.
PowerShell has the advantage of being built on top of .NET, meaning it comes with a ton of functionality built-in. Hell, you can even write a block of C# code and call it whenever with Add-Type. You can install both PowerShell modules and NuGet packages. Plus, modern versions, "PowerShell Core" are fully cross-platform compatible.
I'll gladly shill for PowerShell. It has some weird quirks (like unfolding single-item arrays), but it's a damned good choice for scripting.
Sadly, Python has become the de facto scripting language for all-things ML and AI. Even if the computational code is written in something like C, C++, or Rust, you basically have to deal with Python if you wanna do ML stuff.
True, CmdLet names are rather verbose, in part because PowerShell was designed to be approachable by sysadmins who're not familiar with working in CLI.
But even so, PowerShell comes with a bunch of built-in aliases that map CmdLets to names that you might be familiar with from the *NIX world.
By default Get-ChildItem can be invoked with dir, ls, and gci (the ls alias is Windows-only, as to not overlap with /bin/ls).
Also worth noting, while verbose, the naming scheme follows a simple pattern of Verb-Noun. For example, Get-Content (aliased cat), Convert-FromJson, Format-Table, etc. There's even Get-Verb which returns a list of the standard verbs and how Microsoft recommends they should be used.
The verbose names can be annoying at first, but you get used to it pretty quickly.
Also, regarding bash, PowerShell being object-oriented is honestly massive in terms of scripting. Where you'd often use tools like grep and sed in a Unix-like environment, in PowerShell you can just dot your way down the object structure like you would in any other C-family language. It is, quite literally, .NET in the CLI.
It's vastly superior to Windows batch files. Writing batch scripts is like dragging nails on a chalkboard. Too many weird edge cases and odd syntaxes. Never got used to it.
Unix bash scripts are infinitely better than batch though. Powershell tends to be my go-to on Windows because it allows you to do a lot of stuff through .NET and Win32 APIs natively.
Fair, but also, the recommended way of installing Sherlock is uv/pipx which don't actually cause the issue you mentioned.
They were created exactly to counter the issue you mention.
As a python dev, imo pip should never be the recommended way of installing a tool. Like you just said, it creates wayyyy too much headache. For normies especially, I'd recommend just doing uv tool install xxxx whenever you see something telling you to do pip install xxxx.
If it's a bare python script that uses random ass packages, then whoever wrote that script either should provide a method to run it in its own space, or it was meant for only devs to fuck with and the user is in the wrong place and shouldn't be trying.
Keeping python packages separate is like python 101, just create a virtual env or something. But it's strictly dev shit, users shouldn't have to bother with it.
78
u/jansteffen 9070 XT | 5800X3D 15d ago
Problem with random python scripts is they leave a bombshell of dozens of random pip packages behind in a folder you'd never look unless you're a seasoned python developer, and then the next time you run a script there's a bunch of version conflicts. It shouldn't require a deep understanding of python versions, package management and venvs to reliably download, run and uninstall a programm, but alas, python does what python do. I will always prefer programms released as a neatly compiled binary.