today I learned that running setup.py directly is deprecated.

The more I use python, the less I understand it.

apparently, the correct way to do it is to run pip install . I guess.
@da_667 the goal there is to eventually take arbitrary code execution out of the install path
@jordan @da_667
Whoa boy are they ever going to not like it when they find out what pip is actually installing
@da_667 gotta pay the pipper
@da_667 before i learned how to use venv it was constantly yelling at me for installing things with sudo -H python3 -m pip install <package>, i think in newer versions they just straight up refuse to let you do that now. i'm probably better off now for learning venv because i did end up breaking my entire python install a couple times and had to figure out how to erase everything and reinstall to fix it, which can get tricky if reinstalling your python environment depends on running python lol

@krishean @da_667 Yeah, you need to pass something like --fuck-up-my-shit (paraphrased) to get pip to actually install things outside of a venv on most systems these days, because it can break OS components if there's an incompatibility with the OS-level packages. And can confirm, you do not want to have to debug that.

There's also pipx these days, which is very useful for "self-contained" applications like yt-dlp because it automatically manages the venvs for you and creates wrapper scripts in ~/.local/bin/.

@becomethewaifu @da_667 interesting, i've been managing the venv manually so far when installing yt-dlp, i'll have to check out pipx and see if that simplifies things because it sounds like it does exactly what i'm doing now
@krishean @da_667 As long as you add ~/.local/bin to your PATH, it's literally as simple as pipx install yt-dlp and a few other commands to install some optional deps if needed: pipx inject yt-dlp <package>
@becomethewaifu @da_667 i've usually been using ./venv/bin/python3 -m pip install --upgrade 'yt-dlp[default]' after setting up the venv because somewhere in the yt-dlp docs it said to use the [default] as part of the install command for some reason

@krishean @da_667

Python environment hell is one of the most aggressively cursed things I've dealt with in the last 10 years when trying to just build some freaking labs.

The only thing I can think of that's worse off the top of my head is Powershell module bullshit.

@johntimaeus @da_667 i've had to deal with powershell modules on linux so this is a pain i am intimately familiar with

@krishean @da_667

I spent most of the day discovering the new ways that server 2025 with PS 7.4 embuggered things like
Import-Module GroupPolicy

And outright broke Add-Computer.

I haven't actively Windows touched in a while and the last few work days have convinced me that I will never take a job where Windows is a primary OS.
I say this as someone who used to have a 3 digit MCSA for w2k.

@da_667
curl | sudo python3
@da_667 venv is somewhat confusing but it does work, solves dep issues but i hope they can improve #variables
@da_667 ruby is just as bad. back when i was using metasploit on the daily, there was some weird ruby bullshit to deal with literally every update
@da_667 in England, the correct command is pip pip cheerio
@da_667 I’ve only been using it since version 1.2 and I do feel it’s lost its way in many ways. Often dragged off track in well intentioned ways. And yet every other ecosystem feels materially even worse.

@petrillic I have to agree. Like, for example, I can see the intention of requiring virtual environments for installing custom things via pip, but also, it's the dumbest fucking thing I've ever seen.

"You should use pip to install this required package."

"okay pip install blah"

fuck you. install this python library as a software distribution package provided by your distro (if it even exists in their software repo), or re-run pip with --break-system-packages

@da_667 I hate to recommend uv given it's now associated with Anthropic, but it's about the only tool that I think does mostly what people want and does so reliably. For example, you can just say:

uvx $toolpackagename

And it will create all the venv in a well known place, intsall all the dependencies and then run it. I use this A LOT.

But I feel like Python needs to decide exactly what groups it is not interesting in serving. Because everything to everyone is a shitty proposition that gets you nowhere good.

@da_667 @petrillic

tbh imagine trying to support rhel based distros, debian based distros, arch based distros, gentoo, and whatever other artisinal package manager.

Use a venv or pass the --do-not-open-an-issue-for-this-or-spam-the-mailing-list flag seems like a reasonable compromise.

Also I'm pretty sure rhel based systems stopped shipping with py2.7 but maybe not

@petrillic @da_667

at this point I genuinely don't know if its the devil you know or not for me as I also think go modules and the build system are "pretty straight forward".

I guess when comparing to.. C++?