You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each of them have its third-party dependencies installed with pip install -r requirements.txt.
That raises a risk of conflicting packages.
Although they are installed in 2 different virtual environments, they're still running in the same single Python process that makes it impossible to load 2 different versions of the same package at the same time.
For instance, if wrapper code relies on fastapi==0.100.0, but the job depends on fastapi==0.90.0, there might be the clash, cause the wrapper's library takes precedence when loading modules in Python and the job will use fastapi==0.90.0
I see the only good way out of here: Wrapper code shouldn't have any third-party dependency (that could be overwritten or conflicted by a job). Then, there won't be any conflict. It can either implement the necessary logic on its own or use "forked" versions of libraries (eg. FastAPI renamed to fastapi_racetrack package).
This task has a low priority as it rarely happens to break something (but when it does, it's astonishing and hard to find).
The text was updated successfully, but these errors were encountered:
iszulcdeepsense
changed the title
Better job's requirements isolation
Isolate job's requirements
Jul 14, 2023
A job runs a single Python interpreter process that contains 2 codebases:
Each of them have its third-party dependencies installed with
pip install -r requirements.txt
.That raises a risk of conflicting packages.
Although they are installed in 2 different virtual environments, they're still running in the same single Python process that makes it impossible to load 2 different versions of the same package at the same time.
For instance, if wrapper code relies on
fastapi==0.100.0
, but the job depends onfastapi==0.90.0
, there might be the clash, cause the wrapper's library takes precedence when loading modules in Python and the job will usefastapi==0.90.0
I see the only good way out of here: Wrapper code shouldn't have any third-party dependency (that could be overwritten or conflicted by a job). Then, there won't be any conflict. It can either implement the necessary logic on its own or use "forked" versions of libraries (eg. FastAPI renamed to
fastapi_racetrack
package).This task has a low priority as it rarely happens to break something (but when it does, it's astonishing and hard to find).
The text was updated successfully, but these errors were encountered: