The entire field of Python import statements, their rules and programmatic application, Python dependency management and Python packaging is a horror show that has been going wrong for decades. It's a big part of the reason I left Python for NodeJS ten years ago.
The problem you're referring to is real but 1) there exist package managers like pnpm that mitigate the overall size of NodeJS dependencies by using symlinks; 2) the problem is orthogonal to the ease-of-use and relative architectural simplicity that NodeJS dependency management has when compared to Python's.
In hindsight, Python's idea of using one centralized `site-packages` directory for all the dependencies of all your local projects was a big mistake and is what brought us virtual environments, a needless complication of the state of affairs. Npm did the right thing and opted for per-project dependencies. It took them some time to figure out how to de-duplicate and additionally a lot of talking to people to convince them that sometimes, just sometimes folks, you need to have two versions of the same dependent package in you project, but in the end they swallowed it.
This is a far cry from the terrifying complexity that is Python's import statement and Python's wheels and setuptools and the endless configuration files and the wheels and the zipped archives and so on and so on. Having to learn all that feels like doing a bachelor's degree. Very of it is needed, most of it is self-incurred damage, starting from the 100% superfluous `__init__.py` files and the mere existence of `*.pyc` files. Shudder.
"""However, there is no lock file. You could manually generate a kind of lock file using something like pip freeze >> environment.lock, as this will look at all the packages currently installed in your environment and write them to a file. However, such a manual process is error prone and most people prefer to use a dedicated tool to manage lock files.
"""
"error prone", ok pal, ok -- undermine your entire article with this.
Keep the output of "pip freeze" in version control and you're good to go. When you want to upgrade you need to diff the old to the new. Do the work and stop complaining.
The entire field of Python import statements, their rules and programmatic application, Python dependency management and Python packaging is a horror show that has been going wrong for decades. It's a big part of the reason I left Python for NodeJS ten years ago.
quickly checks the size of my npm packages
Ok sure. Maybe your dependency tree is clean but I at least have some space on my hard drive.
The problem you're referring to is real but 1) there exist package managers like pnpm that mitigate the overall size of NodeJS dependencies by using symlinks; 2) the problem is orthogonal to the ease-of-use and relative architectural simplicity that NodeJS dependency management has when compared to Python's.
In hindsight, Python's idea of using one centralized `site-packages` directory for all the dependencies of all your local projects was a big mistake and is what brought us virtual environments, a needless complication of the state of affairs. Npm did the right thing and opted for per-project dependencies. It took them some time to figure out how to de-duplicate and additionally a lot of talking to people to convince them that sometimes, just sometimes folks, you need to have two versions of the same dependent package in you project, but in the end they swallowed it.
This is a far cry from the terrifying complexity that is Python's import statement and Python's wheels and setuptools and the endless configuration files and the wheels and the zipped archives and so on and so on. Having to learn all that feels like doing a bachelor's degree. Very of it is needed, most of it is self-incurred damage, starting from the 100% superfluous `__init__.py` files and the mere existence of `*.pyc` files. Shudder.
"""However, there is no lock file. You could manually generate a kind of lock file using something like pip freeze >> environment.lock, as this will look at all the packages currently installed in your environment and write them to a file. However, such a manual process is error prone and most people prefer to use a dedicated tool to manage lock files.
"""
"error prone", ok pal, ok -- undermine your entire article with this.
Keep the output of "pip freeze" in version control and you're good to go. When you want to upgrade you need to diff the old to the new. Do the work and stop complaining.
That's how it works, and all of it is terrifying.
calm down, dear. it's not bad if you know how to use the tools effectively. you stick with your "venv activate" bs as well
I don't want no stinkin' `venv` is my point