Skip to content

dependency requests with no version considered harmful #1323

@lgritz

Description

@lgritz

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

  1. any version is fine, for all time
  2. I think this is a dependency whose version is specified by the platforms
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    agenda itemItems to be brought up at the next dev meeting

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions