-
Notifications
You must be signed in to change notification settings - Fork 11
Description
Regarding the issue of "package recipes that specify non-platform dependencies with no versions":
I'm increasingly viewing this as an anti-pattern that causes a lot of problems. We've run into several instances where people do this without realizing the dangers, and then things break when the maintainer of a dependency does a new release that pushes past an important compatibility or behavioral change and breaks other packages that unwisely requested the dependency with no version spec at all. Or, where maintainers hesitate or delay making releases because they don't know what might break, thus preventing people who want the new version from being able to get it.
A few random thoughts (culled from an internal chat) follow:
Is it remotely possible to write a script that crawls all packages and takes a full census of all recipes that have underspecified dependencies at their current latest version?
Alternately, is it possible to make it a default, or at least a site-wide default, to reject dependencies with no version (and also that are not in any platform)?
What is the merit of allowing spk to YOLO in any random dependency version, totally unconstrained?
If you REALLY believe, for your own package, that any version of a dependency is fine, no matter what future versions might do to break compatibility, you can already do dependency/>=1.2.3 or dependency/*, right? But then at least it's an explicit choice to do this unsafe thing, and self-documenting that this is the policy you are choosing.
Whereas if you only say dependency (no version), it's actually not clear (to others, and maybe not even to the package maintainer) if you mean
- any version is fine, for all time
- I think this is a dependency whose version is specified by the platforms
- I forgot to give any constraints, or some other mistake
I will go further and say that we should really have a notation that explicitly means "get the version from the platform" (making case 2 above explicit), and not use unspecified versions for that.
To see why, imagine that today, package foo is part of the platforms, so you don't specify a version for your foo dependency. But next year, we wish to remove it from platforms. But now you can never safely do that without breaking packages unknowingly that lacked a version. Whereas if you had a notion like foo/from-platform, it would be an error to use it in a context where the platform didn't provide a version, so you'd catch this right away.