| Similar experience, but disagree with almost everything you have said. - stick to regular python installers. Don't use homebrew, pyenv, conda, the windows store, etc. For me pyenv has been a lifesaver, easier to manage multiple versions. Are you manually managing multiple python versions? - always use "-m" when you run a python tool, even in venv. This will let you be explicit about which python you use. On windows, use the "py" command to create the venv. Unsure how I feel about this, I do normally point direct to the binary being used rather than using "-m", Although "-m" still requires you to be in the correct venv. How does it allow you to be specific about the python you use though? - if you are in linux, research how to install python seriously. If the command is simple, you probably got it wrong. E.g: Ubuntu has 3 packages to install, not one. People giving you a one true way are lying to you. Pyenv is a trap. poetry has been another lifesaver that removes the boring writing of a setup.{py,cfg}. Pretty much everything can be managed through it, and it feels like a legit build tool for python. No more broken requirements because of a differing versions in transitive dependencies. - learn to use basic venv and pip. Never do something outside of a venv. Not even install black. You can get very far with just that. Can't disagree with this, although poetry will manage your venvs for you. Understanding venv and pip is useful, but not fundamental. Greatest success for devs has been getting them away from manually managing things, by and large perm staff don't care about learning lots of tools well, it's just a job. - if you want to have better tooling, use pip-tools. Not pipenv. Not poetry. Not flint. Not pdm. Not anything else. They will fail you. Pip-tools is just good enough and just reliable enough. Embrace manual venv handling. It's not a big deal. Automated tools will betray you. lumping poetry in with pip-tools is weird. it's not a replacement, it's a tool with greater scope than pip-tools. pip-tools provides a subset of poetry functionality i.e. dependency management. Manual handling is useful to learn, but is laborious after a while, hence tools such as poetry. - learn to be comfortable with the PATH and the PYTHONPATH. No matter what you do, something may need tinkering. This is a really interesting point, normally modifying PYTHONPATH is a smell in my experience, but yes is good to understand. Understanding the PATH in general is more useful as a dev than specific to python imo. - tox is indeed the best tool to test several envs, but people that need it are rare. Don't bother for now. Agreed, its a nice thing to do, but rarely do I see it unless you are building libs, and need to support multiple versions. - if you want to build a package, use hatch. But you probably don't. Why would you use hatch over a tool such as poetry, are they equivalent? I'm interested in exploring hatch, but the comparisons I have found seem to be fundamentally misinformed about poetry so its hard to take comparison seriously. - if you have to use conda, don't use pip or venv at all. Don't use piptool, poetry or anything. Stay on pure conda land. It sucks, but the alternative of mixing them is worse. This is a really good point, but is always a frustrating thing to try and solve time and time again, but still encounter problems. |
Because it's a sure sign that you have not had to help a team of geographers in a school or quants in banks or small kids.
Your method will only work for a very small subset of python users, and you don't have met enough of them to even know what error they encounter.
It's ok, you are a skilled dev, you offer skilled devs advices.
But no, pyenv has too many ways to fail for the average python users. Espacially since the "py" command on windows and suffixed python on mac and linux works fine to deal with multiple versions.
If would be too long to debate each point so I won't. But I don't make those claims out of the will to be right or contradict people.
I worked with python since 2.4, in dozens in countries. In africa. In asia. In the silicon valley.
It gave me a huge sample to study.