4 ms·

Wouldn't this be less of an issue if you could say '[org.clojure/clojure ">1.2.0"]'? Or any of the other version number matching formats rubygems, npm, cargo,

Wouldn't this be less of an issue if you could say '[org.clojure/clojure ">1.2.0"]'? Or any of the other version number matching formats rubygems, npm, cargo, or any of the other package managers seem to manage?

nathell 7y ago
You can, but this is discouraged. Unlike in other version management systems, Clojure tools do not use lockfiles; you're expected to be explicit about the version numbers you want. https://nelsonmorris.net/2012/07/31/do-not-use-version-ranges-in-project-clj.html https://nelsonmorris.net/2012/07/31/do-not-use-version-range...
- regularfry 7y ago
  Why no lockfiles? I'm sure there's a reason, I just don't know what it is.
  - nathell 7y ago
    This question merits a detailed answer that I can't provide right now, but here are some pointers: https://hypirion.com/musings/lockfiles-are-not-the-only-option https://hypirion.com/musings/lockfiles-are-not-the-only-opti... https://stackoverflow.com/questions/44521542/why-doesnt-gradle-or-maven-have-a-dependency-version-lock-file https://stackoverflow.com/questions/44521542/why-doesnt-grad...
    - regularfry 7y ago
      All those links really tell me is that the problem lockfiles solve has been arbitrarily ignored. "A solution can exist, it's just not currently implemented" seems to be the state of things, unless I've misread it. I'm all up for saying "thou shalt specify precise versions of library dependencies", but the specific case of `org.clojure/clojure` seems qualitatively different in that a precise version influences your consumers, and leaving it unspecified means your library might not work at all.
diggan 7y ago
> Wouldn't this be less of an issue I'm not sure I understand what issue you would solve with using "[org.clojure/clojure ">1.2.0"]" compared to what we're doing today, which is specifying the exact version we're using. What is the issue you're addressing here exactly? In general, the Clojure community favors stability (more than others like npm) when it comes to dependencies, so you're almost always defining the exact version of the dependency you want.
- regularfry 7y ago
  The exact issue I'm addressing is where a library wants to specify that it can only be used with a version of clojure later than 1.2.0 (in this case). The problem the author is talking about is when a library forces a language version on its users because it either specifies no version at all, or has to specify a specific one. I'm not sure I understand how `:scope "provided"` plays out if two dependencies say they want different versions of clojure, but that's also relevant.
  - diggan 7y ago
    > I'm addressing is where a library wants to specify that it can only be used with a version of clojure later than 1.2.0 That sounds like a solution to some problem, but I'm unsure of what that problem is. Not sure it makes sense to depend on more than one version at a time, because you're usually just testing with one version and can ensure compatibility with just one version. Semver somehow made people believe that we can have versions numbers created with human-intuition but used as they are 100% true and generated by robots.
    - regularfry 7y ago
      Oh yeah, semver is mostly bunk. You can get most of what you need from a single incrementing version number. Look at it this way: say library A expresses a dependency on clojure 1.8, and library B on clojure 1.9. As the author of application C wanting to depend on both, what do I do when I want to use 1.10?

nathell 7y ago

You can, but this is discouraged. Unlike in other version management systems, Clojure tools do not use lockfiles; you're expected to be explicit about the version numbers you want. https://nelsonmorris.net/2012/07/31/do-not-use-version-ranges-in-project-clj.html https://nelsonmorris.net/2012/07/31/do-not-use-version-range...

regularfry 7y ago
Why no lockfiles? I'm sure there's a reason, I just don't know what it is.
- nathell 7y ago
  This question merits a detailed answer that I can't provide right now, but here are some pointers: https://hypirion.com/musings/lockfiles-are-not-the-only-option https://hypirion.com/musings/lockfiles-are-not-the-only-opti... https://stackoverflow.com/questions/44521542/why-doesnt-gradle-or-maven-have-a-dependency-version-lock-file https://stackoverflow.com/questions/44521542/why-doesnt-grad...
  - regularfry 7y ago
    All those links really tell me is that the problem lockfiles solve has been arbitrarily ignored. "A solution can exist, it's just not currently implemented" seems to be the state of things, unless I've misread it. I'm all up for saying "thou shalt specify precise versions of library dependencies", but the specific case of `org.clojure/clojure` seems qualitatively different in that a precise version influences your consumers, and leaving it unspecified means your library might not work at all.

diggan 7y ago

> Wouldn't this be less of an issue I'm not sure I understand what issue you would solve with using "[org.clojure/clojure ">1.2.0"]" compared to what we're doing today, which is specifying the exact version we're using. What is the issue you're addressing here exactly? In general, the Clojure community favors stability (more than others like npm) when it comes to dependencies, so you're almost always defining the exact version of the dependency you want.

regularfry 7y ago
The exact issue I'm addressing is where a library wants to specify that it can only be used with a version of clojure later than 1.2.0 (in this case). The problem the author is talking about is when a library forces a language version on its users because it either specifies no version at all, or has to specify a specific one. I'm not sure I understand how `:scope "provided"` plays out if two dependencies say they want different versions of clojure, but that's also relevant.
- diggan 7y ago
  > I'm addressing is where a library wants to specify that it can only be used with a version of clojure later than 1.2.0 That sounds like a solution to some problem, but I'm unsure of what that problem is. Not sure it makes sense to depend on more than one version at a time, because you're usually just testing with one version and can ensure compatibility with just one version. Semver somehow made people believe that we can have versions numbers created with human-intuition but used as they are 100% true and generated by robots.
  - regularfry 7y ago
    Oh yeah, semver is mostly bunk. You can get most of what you need from a single incrementing version number. Look at it this way: say library A expresses a dependency on clojure 1.8, and library B on clojure 1.9. As the author of application C wanting to depend on both, what do I do when I want to use 1.10?