Nov 15, 2023·edited Nov 15, 2023Liked by Bite Code!
In section 5, you might want to emphasize a bit more that exactly “python -m” should be used, with “python” per se as the base command—rather than the “py -3.8” or “python3.8” or whatever exact command it was that you (if *and only if* your faded memory from _n_ weeks ago is exactly correct) created the venv with in the first place.
I suppose this doesn’t affect anything if you only have runtimes from the exact source you recommend in your article, but it is necessary to keep you safe and healthy in any edge cases where you (whether accidentally or knowingly) have Python runtimes from different sources installed on the same machine—e.g. a Python.org-sourced one, plus a company internal one; or if you're on Linux and happen to *have* a personally patched CPython of the same version as the system one, which you use for only some of your projects. Or even if you had to use the Windows-Store provided runtime, for some reason—that would prevent any problems from occurring once the venv exists!
Thanks for the great article! I am also someone who pushes the simple use of python / venv / and pip on all of our python teams. IMHO the "Batteries Included" approach is often the simplest and least error prone.
However one thing I did not 100% agree with, was to "not use pipx". In my experience, when building and packaging in house CLI tools written in python (and hosting them in a private artifact repository) pipx is an excellent way to recommend engineers install those tools and run them without having to worry about manually setting up an venv and installing the dependencies. I also don't have to worry about writing some install script that automates what pipx does for them.
Wondering if you have had some bad experiences with pipx across teams, and if so, what were they? I would be very interested to hear about them.
"The naming around virtual environment is messed up. First, virtual environments are just glorified directories. Do not think they are something special like a virtual machine. Secondly, we tend to abbreviate the concept of “virtual environment” as “venv” or “virtualenv”, which is unfortunate, since it’s also the name of some tools to create virtual environments. This makes the whole situation confusing."
Just have seen that. The "glorified directories" thing I've learnt today. Because of your articles. Thanks again for that!
Fun story: I once read an article written by a guy who was complaining about the Python naming convention heavily. He wasn't using Python a lot. I believe it's often too easy to critisize if you don't have deeper knowledge, even if you have a lot of dev knowledge in another area.
Finally no coding tech is perfect.
But it's true: There's pipenv, pyenv, venv, virtualenv, pypi, pypy, and so on lol. But Python's advantages by far outweigh these minor confusions.
Maybe targeting 4 versions older isn't the greatest idea either. As of writing this comment, Python3.7 goes out of support in about a week. At the time the article was written, there was about 3 months to go.
In the near future, minor version upgrades of Python will involve more deprecated features being removed. I think 3.9 is the last easy upgrade. 3.10 involves many more breaking changes. You want to give yourself some time to do the upgrade.
I am using standard Python with pip and venv on Windows as described here.
If I come across a project that uses a Conda environment.yml file, how can I use pip to install the dependencies?
Here's such a project:
https://github.com/Audio-AGI/AudioSep
In section 5, you might want to emphasize a bit more that exactly “python -m” should be used, with “python” per se as the base command—rather than the “py -3.8” or “python3.8” or whatever exact command it was that you (if *and only if* your faded memory from _n_ weeks ago is exactly correct) created the venv with in the first place.
I suppose this doesn’t affect anything if you only have runtimes from the exact source you recommend in your article, but it is necessary to keep you safe and healthy in any edge cases where you (whether accidentally or knowingly) have Python runtimes from different sources installed on the same machine—e.g. a Python.org-sourced one, plus a company internal one; or if you're on Linux and happen to *have* a personally patched CPython of the same version as the system one, which you use for only some of your projects. Or even if you had to use the Windows-Store provided runtime, for some reason—that would prevent any problems from occurring once the venv exists!
You should flip rules 3 and 4!
You can still use pip with conda, if and only if you have a conda environment activated.
Thanks for the great article! I am also someone who pushes the simple use of python / venv / and pip on all of our python teams. IMHO the "Batteries Included" approach is often the simplest and least error prone.
However one thing I did not 100% agree with, was to "not use pipx". In my experience, when building and packaging in house CLI tools written in python (and hosting them in a private artifact repository) pipx is an excellent way to recommend engineers install those tools and run them without having to worry about manually setting up an venv and installing the dependencies. I also don't have to worry about writing some install script that automates what pipx does for them.
Wondering if you have had some bad experiences with pipx across teams, and if so, what were they? I would be very interested to hear about them.
Thanks!
"The naming around virtual environment is messed up. First, virtual environments are just glorified directories. Do not think they are something special like a virtual machine. Secondly, we tend to abbreviate the concept of “virtual environment” as “venv” or “virtualenv”, which is unfortunate, since it’s also the name of some tools to create virtual environments. This makes the whole situation confusing."
Just have seen that. The "glorified directories" thing I've learnt today. Because of your articles. Thanks again for that!
Fun story: I once read an article written by a guy who was complaining about the Python naming convention heavily. He wasn't using Python a lot. I believe it's often too easy to critisize if you don't have deeper knowledge, even if you have a lot of dev knowledge in another area.
Finally no coding tech is perfect.
But it's true: There's pipenv, pyenv, venv, virtualenv, pypi, pypy, and so on lol. But Python's advantages by far outweigh these minor confusions.
If you want to “Always use pip in a virtual environment” maybe its a good idea to alias pip like
alias pip=pip --require-virtualenv
To allow pip to only run in a virtual environment; exit with an error otherwise.
Maybe targeting 4 versions older isn't the greatest idea either. As of writing this comment, Python3.7 goes out of support in about a week. At the time the article was written, there was about 3 months to go.
In the near future, minor version upgrades of Python will involve more deprecated features being removed. I think 3.9 is the last easy upgrade. 3.10 involves many more breaking changes. You want to give yourself some time to do the upgrade.