Start writing here...
5 python depends problems or python depends Bobm.
1. Specify the exact names of the libraries.
If we specify in requirements.txt names without versions like fastapi instead of fastapi==0.115.1
, this may lead to a situation where, in another environment, for example, in docker, we will install newer versions of dependencies and dependencies, which may
a) contain a bug
b) break backward compatibility.
I've seen this in production servers.
2. The problem of sub-dependencies
Have only one dependency file. So we figured out what dependencies we need to specify exactly. But here's the problem: almost every python project (package) has many sub-dependencies and they are installed automatically, and the problem is that most packages do not strictly control their dependencies, for example, the same fastapi just uses the > sign. Accordingly, even if we specified the Main dependency (of the first one) with the exact version, the dependency in production may also be newer and have the same problems
a) contain a bug
b) break backward compatibility
To solve this problem, we need to specify the exact tree of all the sub-dependencies. For example, through freeze. This will solve this problem, but we still have other problems, so it's not a worthwhile solution.
3. Update problem
So now that we have freeze in our requirements.txt it would seem that the problem has been solved. But no. In fact, now we have a problem with updates, because all versions of all packages are nailed down. Now, if we change any version of the package, it may cause either the package that uses it to break or, conversely, it will break itself, since its dependencies will be old. And it's good if the dependency versions are exactly hammered into the package and you will see this when installing pip, but if not, there will be potential errors in the product. It turns out that each python package hopes that its dependencies will be working and those for others, but this is not guaranteed. And such errors really start to appear very slowly with the increasing complexity of packages and the development of python.
So to solve this, one of the options is to have another file, requirements.txt which will contain all the top-level dependencies and requirements.freeze.the txt that contains the tree.
And now if we want to upgrade, we need to update the package version in the first file with the first-level dependencies, then make a freeze in the second file. And this will almost solve all the problems, except for one thing, let's move on.
4.Cross-platform
So everything seems to be fine. We can easily update the entire package tree, and even this package tree is clearly fixed. And in theory, production and we should have the same environment as on a work computer.Almost. Unfortunately, there are python packages that depend on the operating system, for example, uvloop is not available on windows, although it significantly speeds up the operation of web servers. And what happens if freeze is made from a windows computer, of course it won't get there because in the first file with the upper levels we'll declare it like uvloop==0.21.0; sys_platform != 'win32'. And there won't be any mistakes in our freeze. And now the final stage. Assemblers come to meet us, for example, pip-compile, which will generate reuiremetns.txt and add the line uvloop==0.21.0; sys_platform != 'win32'.You may ask why the python creators didn't do this as a setup for freeze or as a separate command? I don't know. I think such dependency problems are still extremely rare...But with each new package and refinement, the chance has increased.
5. Crossover dependencies
And it would seem that everything is fine with the collector. There are no problems. But in fact, there is another rare problem. Imagine that two packages that are independent of each other use the same dependency. But one is version 1.0.0 and the other is 2.0.0, and both versions are not compatible with each other. Which version will python deliver?it doesn't matter which page the code will work incorrectly in both cases. But so far, by a happy coincidence, this is not happening. But the bomb will explode someday.