Let me preface this by saying thank you for your insightful response, and the many suggestions - I'm definitely going to revalidate some of my assumptions and t

Let me preface this by saying thank you for your insightful response, and the many suggestions - I'm definitely going to revalidate some of my assumptions and try to package that app again! I peaked at the documentation, but found it both overwhelming and unfocused, thus hard to follow. As you say, it's focused on specific tools and feels more like a reference than actual instructions for what I was aiming to do. > One thing I'll offer is that, in the Python world, "managing dependencies" is distinct from "packaging". This seems to be different from other language ecosystems, where there is 1 package management tool that does everything. That might be the actual thing that stumped me: I don't intend on publishing my package somewhere publicly, but simply enable other devs on the team to install the required dependencies with a single command, without any assumptions on their environment, which seems awkward to me. > That said, I take serious issue with the claim in the article that you quoted: >> Nobody knows how to correctly install and package Python apps. > This simply is not true. There are lots and lots of Python applications that are packaged and that you can install without a problem. You can complain about the need for virtual environments instead of having "app-local" packages by default, sure. But that's not the issue in most cases. That is because we understood that quote differently. In your post you mention Pip, Pipenv, Poetry, Setuptools, PyPI, and Conda. Additionally I came across Virtualenv, and Pyenv. All of these tools are somehow related to python packages and dependency management, and everyone on the internet seems to have their own opinion one which combination is the best. There seems to be no consensus on one of the most foundational tasks in software engineering, namely sharing code with other people. To me that counts as nobody knowing how to it correctly. That said, reading the docs again, which clearly recommend using Pipenv - and that seems to be simple enough - I probably should have headed for the official docs right away. > These are NOT easy applications when it comes to packaging. I noticed that :) Caused me to hit the wall multiple times, for example while using Alpine Linux/MUSL and wondering why the C bindings had to be compiled on every install. But you're right, that would bring its own complexities in every language and might be partially responsible for my general frustration with python dependencies. While the scientist didn't use Conda (I think he just happily installs everything he needs globally), that was the recommendation I found on one of his primary packages' website (I think it was pandas), so I followed through and tried to set things up using Conda. It was a nightmare, frankly. I'm really not opposed to learning new things. And I get that my assumption that packages live inside an application directory by default might be just that, and colored by other ecosystems I'm more used to. And, as I said earlier, I'm definitely going to check out Pipenv and try to refactor that thing into something more standards-compliant. Still, I think Python places more roadblocks than necessary in your way, and the combination of bad docs, several opinions on how to do basic stuff, as well as the bad habit of global dependencies, make it difficult for newbies to deal with Python. Which, all in all, confirms the statement in TFA for me: Don't use Python for internal tools. And frankly, as someone affected by Python packaging, I'm definitely going to complain on forums as much as I want if things are harder than they have to be. Just because other systems have their warts too doesn't mean there's nothing to improve.