Python Requirements Ignoring Extra Packages
Hello there! I’m working with Cog and specifying a requirement like transformers[torch]==0.49.0. However, I’ve noticed that the extra package (i.e., torch) is currently being ignored.
Expected Behavior
Transformers should be installed with the specified extra packages.
Description
After some research, I found this pull request: https://github.com/replicate/cog/pull/2160
In versions prior to this PR, using transformers[torch]==0.49.0 would raise an error in SplitPinnedPythonRequirement:
https://github.com/replicate/cog/blob/60017a92ed0e15d8e048fe0552e802bb214827b7/pkg/config/requirements.go#L85-L91
Meanwhile, pythonPackageForArch treated it as an unpinned dependency, which unintentionally but worked:
https://github.com/replicate/cog/blob/2a0763ac6342513fc40c174e63b0dc37ff562a77/pkg/config/config.go#L397-L401
After version 0.14.0, SplitPinnedPythonRequirement no longer raises an error, but the extra package is completely ignored:
https://github.com/replicate/cog/blob/2a0763ac6342513fc40c174e63b0dc37ff562a77/pkg/config/requirements.go#L8-L50
Thanks, good find! You meant transformers[torch]==4.49.0 right?
I'm reverting this in #2211, as it's no longer needed for the fix I was attempting.
IIUC transformers[torch] just adds torch as an extra dependencies right? A few things to consider down the road:
-
python_packagesis deprecated in favor ofpython_requirements, and in the future we might pass requirements as is topip installto avoid such issues - It's recommended to set
torch==x.y.zexplicitly, and this might be required in the future
Meanwhile can you try replacing [torch] with a separate entry of torch==x.y.z as a workaround?
Thank you for the quick response.
transformers[torch] was just an example. I understand that explicitly specifying torch==x.y.z is generally better, especially since Cog performs compatibility checks.
I also noticed that python_requirements is intended to replace python_packages, but the current implementation still seems to parse requirements.txt the same way. That’s why I opened this issue.
Moreover, I think passing requirements.txt directly to pip install is a great approach. I appreciate your work on this and look forward to seeing it implemented.
Yeah you're correct that they still go through the same path, so this is not really solved. But we'll pass requirements.txt as is in the future (soon) to avoid having to deal with such bugs. For now we just prefer to not attempt fixing a problematic code path and cause more regression. That's why I'm proposing the workaround for now.
Somewhat related accidental discovery: we prefer (and will require) a specific torch==x.y.z anyway to prevent accidental breakage from torch upgrades, instead of [torch] pulling the latest. So we'll address that separately.