Hi @ScyLukb ,
This is a common and frustrating problem that occurs when the Model Serving environment's built-in dependencies conflict with your model's specific requirements.
The root cause is that the Model Serving environment tries to install its own default version of mlflow (in your case, 2.2.2) before or instead of processing your custom requirements.txt file. This default version then conflicts with the one you've specified, or the environment setup simply ignores your file for that specific package.
To avoid this and force Model Serving to use your exact package versions and index URL, you must log the model with an explicit conda.yaml environment file that defines the entire environment.
This approach overrides the serving environment's defaults.
Solution: Log the Model with a conda.yaml File
Instead of just providing a requirements.txt file, you will manually define the Conda environment, including the pip section. This is the most robust way to control the serving environment.
Why This Works
-
Explicit > Implicit: By providing a full conda.yaml, you are explicitly defining the entire environment. You are no longer "suggesting" requirements with a requirements.txt but are instead "demanding" this exact environment.
-
Overrides Defaults: Model Serving will see this conda.yaml file and build a new, custom environment based on it, rather than trying to use its default environment image (which contains the problematic mlflow==2.2.2).
-
Correct pip Context: Placing the --index-url inside the pip: section ensures it's passed to the pip install command within the Conda environment as it's being built, so it can find all your custom packages.
