cfchase
commented
11 months ago If you're in a 100% control of the dependencies (as you would be on a minimal image without pre-installed dependencies), pinning to a specific x.y.z is great at the end of a dev cycle, e.g. pip freeze. However, if there are preinstalled dependencies that are changing, they are going to change very often and notebooks are inherently for "development" and in any given project the lockfile is getting updated constantly.
This is especially true for the boto versions that are in here. They're going to be wrong on almost all base images and attempt to uninstall/reinstall, etc. We can loosen the restrictions so that it won't cause so much heartache during development. If the version changes and there's a breaking change, we could lock it to a major version or do a min/max, but pinning to an exact version is too brittle. I just left the versions off because it's going to take the least maintenance, but we can pin it to something (more general) if we find that upgrading to the latest breaks something.
I won't have time to test, but I'm curious as to why this is the fix. typically, I always prefer to pin to specific versions. why does un-pinning help here? and isn't there a risk this could break again in the future? when one of these packages update to another version, for example?