Python local packages directory proposal rejected (PEP 582)
It&#x27;s so weird to me that anyone would prefer their project&#x27;s dependencies be at some arbitrary location on disk rather than simply inside the current directory. But sure, whatever, do what you like. What&#x27;s <i>even weirder</i> to me is that people would advocate stopping anyone else from doing this. There are comments on that thread even denigrating users who don&#x27;t prefer this as &quot;not understanding directories.&quot; Are you kidding me?!<p>The devs in this thread are all arguing from the perspective of &quot;not making things more confusing,&quot; but it&#x27;s like they haven&#x27;t even considered that things are so confusing at this point, that people are just abandoning Python altogether. And how can anyone in good conscience recommend it as a first programming language to some poor noob who&#x27;s going to spend hours dealing with the packaging mess every time they try to code a new project or return to their last one?<p>I have a bunch of small python projects that I come back to once every six months, and every time, it&#x27;s a nightmare to remember how to activate the venv for them, and then also to remember which venv it&#x27;s actually using. Not to mention I need to search the internet to remember the difference between venv, pyenv, virtualenv, pyenv-virtualenv, and at one point even &quot;virtualenv-burrito.&quot; Then it&#x27;s a constant struggle with ~&#x2F;.bash_profile and ~&#x2F;.bashrc to figure out why the activate script isn&#x27;t working. Do I need to activate it? Do I need to exec it in  subshell? Once I finally figure it out, should I put this in my .bash_profile or is it a waste of time to check whether to activate a venv on every command I type? Two hours later, if I&#x27;m lucky, I can actually start coding on the project where I left it six months ago.<p>It&#x27;s a total nightmare and ultimately the main contributor to what turned me off of Python. TypeScript has its problems, but at least I&#x27;ve got a yarn workflow with immutable lockfiles that pretty much guarantees I can jump back into a project how I left it, and I don&#x27;t need to also worry about some state in my home directory, or environment variables missing in my shell, or activating some opaque venv in every new tmux pane. I can <i>see</i> the dependencies in node_modules. They&#x27;re right there. Nothing outside of my current directory is relevant to the project at all.<p>This same criticism applies to go and their $GOPATH. Rust is slightly better. I&#x27;ve started keeping a note in Obsidian for each of these languages, called e.g. &quot;cold jumping back into Rust,&quot; which lessens the pain each time, but I haven&#x27;t made these notes for Python yet and I&#x27;m not exactly thrilled every time I need to jump back into a Python project.