I'm a C and C++ dev, using some python tooling here and there to make my life easier. I've been using -m since forever. I kinda settled into it naturally. What issues can it cause?
I have to tell, first you make me mad! I did not agree. pyenv - works, packaging work, installing on system wide with pip works... Then I realize you kind of right...
I'm maintainer a small windows desktop app (probably used by less then 100 people). It available as python package at PyPI, but be installed with pip. I did what most developer would do release as whl, allow to install and been updated with pip, simple stuff.
But it turn out most of users are non-developers... I realize it when I got really simple question like: that is terminal, what is cmd, where to put command (pip install dcspy), I got weird output, it is correct or not.... Once, one user reinstall whole windows because he got some strange message/question (normal from developer perspective behavior).
So, yes... we developers solve dozen of simple problem daily, don't realize it... love to tinkering...
So now I just deliver one-file executable (done with pyinstaller/nuitka) and keep wheel as backward compatibility.
Thanks for the fun read, however I don't understand how you are suggesting to manage different Python versions without pyenv (or similar). eg. new projects that have been written to use tomllib for configuration and require Python 3.11 or newer. The user is on Debian 11, which ships with Python 3.9.
You say to use -m but that won't help me get Python 3.11 or above. You say we should be using binaries. From where? python.org only provides source for anything but Mac and Windows. What you are proposing seems to create an entirely new problem that should not exist.
You have seemingly worked with about a hundred paying clients, so I suspect part of the problem is that your experience is somewhat skewed. It doesn't seem to match up with the needs of the Python and free software communities that arguably care about Python the most.
Feel free to correct me if I have misunderstood something.
Jun 20, 2023·edited Jun 20, 2023Liked by Bite Code!
Thanks for that article. Though I've only slimmed over it, I've found a lot of great points.
I've always used pipenv for my projects. And the "only" problem that I sometimes have is with "pipenv lock". But your article made me aware now that this is actually not good, because when I one day will have to port all of my projects to a new computer, I might deeply regret not having working pipfile.lock files for all of my projects. Must admit that I haven't taken this serious enough. But I've already figured out a workaround.
Probably I'll use venv from now on. No hassle with pipenv.lock not working.
But one thing makes me clueless: How do you achieve building venvs via "python -m venv name_of_venv" with a specific python version when not using pyenv? Do you install the wished version globally then and select the wished python binary when creating the venv? Not sure if it's even possible or advised to install multiple Python versions globally. I'm on macOS and always use the official installer from the Python website to install Python globally. But I've never tried installing multiple of them. Is that good or even possible?
EDIT: Ah ok, reading parts of your article again, on Mac you should do something like "python3.8 -m venv .venv". But does that mean I can install several Python versions safely using the official installer?
I believe it's worth to read your article completely. Will do it soon.
Jun 20, 2023·edited Jun 20, 2023Liked by Bite Code!
I reduced my complexity by retiring and now just program my own projects.
The complexity I once ranted about was compiled (and linked!) programs. Keeping track of all the parts was a pain (where's the code for that exe?). Having everything in one place with a script (yea python) was great. I love git, but a self contained script and normal incremental backups worked fine too.
I couldn't figure out what venv was trying to solve, until I started to install new versions of python to try out. Boy did that mess things up. Never figured out a good recipe for deploying a python program with a venv. I just pay better attention to which python version I'm using (tell vscode which to use) and what is installed at the deployment site. Never use the latest and greatest python. Never.
I am tempted to get back to using types with python type hints, but a python strength was it could figure out types just fine. My first foray with type hints and I spent more time tracing type issues that just then went away when I finally ripped out all the type hints. I do want to hover over a variable and see the full type. <sigh>
Very verbose (as I often am) but still interesting to read.
Only empathic progrmmers understand this misery, when watching how knowledge is aquired the wrong way and everybody has a strong opinon on a direction to solve it. You described it so cleary, that i wished i could. A really wonderful article about a fundamental problem in IT and for the masses of people touching programming interfaces and languages that we now are.
I was reading your article while dealing with an Streamlit Cloud deployment ordered at last minute that should be ready for the next day. The installation was a pain, but your article was a relief. Thanks for your advice.
Big fan of pyenv-virtualenv when showing other developers who are less familiar with python how to get set up (appreciate a different audience to normies)
I'm a C and C++ dev, using some python tooling here and there to make my life easier. I've been using -m since forever. I kinda settled into it naturally. What issues can it cause?
I have to tell, first you make me mad! I did not agree. pyenv - works, packaging work, installing on system wide with pip works... Then I realize you kind of right...
I'm maintainer a small windows desktop app (probably used by less then 100 people). It available as python package at PyPI, but be installed with pip. I did what most developer would do release as whl, allow to install and been updated with pip, simple stuff.
But it turn out most of users are non-developers... I realize it when I got really simple question like: that is terminal, what is cmd, where to put command (pip install dcspy), I got weird output, it is correct or not.... Once, one user reinstall whole windows because he got some strange message/question (normal from developer perspective behavior).
So, yes... we developers solve dozen of simple problem daily, don't realize it... love to tinkering...
So now I just deliver one-file executable (done with pyinstaller/nuitka) and keep wheel as backward compatibility.
Great reed...
I wrote a comment here last night which didn't seem to appear, but it did appear on Notes, if anyone is interested:
https://substack.com/profile/62817-bjkeefe/note/c-17558557
Thanks for the fun read, however I don't understand how you are suggesting to manage different Python versions without pyenv (or similar). eg. new projects that have been written to use tomllib for configuration and require Python 3.11 or newer. The user is on Debian 11, which ships with Python 3.9.
You say to use -m but that won't help me get Python 3.11 or above. You say we should be using binaries. From where? python.org only provides source for anything but Mac and Windows. What you are proposing seems to create an entirely new problem that should not exist.
You have seemingly worked with about a hundred paying clients, so I suspect part of the problem is that your experience is somewhat skewed. It doesn't seem to match up with the needs of the Python and free software communities that arguably care about Python the most.
Feel free to correct me if I have misunderstood something.
Thanks for that article. Though I've only slimmed over it, I've found a lot of great points.
I've always used pipenv for my projects. And the "only" problem that I sometimes have is with "pipenv lock". But your article made me aware now that this is actually not good, because when I one day will have to port all of my projects to a new computer, I might deeply regret not having working pipfile.lock files for all of my projects. Must admit that I haven't taken this serious enough. But I've already figured out a workaround.
Probably I'll use venv from now on. No hassle with pipenv.lock not working.
But one thing makes me clueless: How do you achieve building venvs via "python -m venv name_of_venv" with a specific python version when not using pyenv? Do you install the wished version globally then and select the wished python binary when creating the venv? Not sure if it's even possible or advised to install multiple Python versions globally. I'm on macOS and always use the official installer from the Python website to install Python globally. But I've never tried installing multiple of them. Is that good or even possible?
EDIT: Ah ok, reading parts of your article again, on Mac you should do something like "python3.8 -m venv .venv". But does that mean I can install several Python versions safely using the official installer?
I believe it's worth to read your article completely. Will do it soon.
I reduced my complexity by retiring and now just program my own projects.
The complexity I once ranted about was compiled (and linked!) programs. Keeping track of all the parts was a pain (where's the code for that exe?). Having everything in one place with a script (yea python) was great. I love git, but a self contained script and normal incremental backups worked fine too.
I couldn't figure out what venv was trying to solve, until I started to install new versions of python to try out. Boy did that mess things up. Never figured out a good recipe for deploying a python program with a venv. I just pay better attention to which python version I'm using (tell vscode which to use) and what is installed at the deployment site. Never use the latest and greatest python. Never.
I am tempted to get back to using types with python type hints, but a python strength was it could figure out types just fine. My first foray with type hints and I spent more time tracing type issues that just then went away when I finally ripped out all the type hints. I do want to hover over a variable and see the full type. <sigh>
Very verbose (as I often am) but still interesting to read.
So true but I’d love to just use pip, but there is no way I can get tensor flow or scikit learn to work on my machine without conda.
Only empathic progrmmers understand this misery, when watching how knowledge is aquired the wrong way and everybody has a strong opinon on a direction to solve it. You described it so cleary, that i wished i could. A really wonderful article about a fundamental problem in IT and for the masses of people touching programming interfaces and languages that we now are.
Switched to C# a couple of years ago, don't miss this nonsense. Should have done it WAY sooner, like around the PY3K disaster.
I really like this article and the "Relieving your ...pain" article before that. Can't wait for you to publish all those other ones you mentioned ...
I was reading your article while dealing with an Streamlit Cloud deployment ordered at last minute that should be ready for the next day. The installation was a pain, but your article was a relief. Thanks for your advice.
Big fan of pyenv-virtualenv when showing other developers who are less familiar with python how to get set up (appreciate a different audience to normies)