3 ms·

tools.deps, which is mentioned above, is the official solution. It's been around for more than a few years.

by casion 4y ago

brundolf 4y ago
This was in mid 2019, so I'm not surprised things have evolved since then. It's good they've got an official solution now, but when official tooling only gets introduced to an ecosystem after the fact, there often ends up being a schism in the ecosystem that can keep hurting for a long time; just look at Python (it's far from a perfect comparison, but still). And the original comment reads like a confirmation that this is happening with Clojure: > Leiningen, the older and still quite popular way > borkdude’s new project seems to be trying to bridge the gap by providing some pre-canned equivalents of popular Leiningen commands, but built on top of deps.edn. Instead of lein this is neil. Maybe the story will be different for Clojure and people really will converge on the official solution eventually, who knows
- didibus 4y ago
  I think in 2007, when Clojure first released, it wasn't common the way it is now that a language comes already with a full set of official tooling maintained alongside it. I feel this trend started later on. That said, it's also because Clojure is not its own runtime, so its actual tooling is the same as Java's. This is how it started, just expecting you'd use Maven as was standard in Java back then. Its the community that kind of decided they didn't like to use the Java tooling and on their own brought Clojars and Lein as replacement. So I think that's why at first there wasn't any, and later the core team thought, okay, well, if people want Clojure tooling and don't want to just Maven as maybe it was first intended, then they'd rather take it over and do it how they think is best. This is my interpretation of the history at least.
  - brundolf 4y ago
    That makes sense, thanks for the context
- casion 4y ago
  Yes, there is a divide in the ecosystem for existing projects and knowledge, however new projects have a choice between two excellent, well documented and capable toolchains with sizable populations. I understand that as a beginner this is painful. You generally want to be told what to do with tooling, then ignore it for a while when you learn the language. As you mature as a developer in that ecosystem, the choices become a great benefit. It's true in Python as in C as in Common Lisp as in Clojure. I am a professional Clojure developer, and despite using Leiningen for many years I would say right now that I barely even know how to create a project or how to read a non-trivial project.clj. tools.deps on the other hand I feel confident with and believe it's one of the better systems out there. There are people who feel the opposite (in all ways), and I think that's _awesome_.

tools.deps, which is mentioned above, is the official solution. It's been around for more than a few years.

by casion 4y ago

tools.deps, which is mentioned above, is the official solution. It's been around for more than a few years.

This was in mid 2019, so I'm not surprised things have evolved since then. It's good they've got an official solution now, but when official tooling only gets introduced to an ecosystem after the fact, there often ends up being a schism in the ecosystem that can keep hurting for a long time; just look at Python (it's far from a perfect comparison, but still). And the original comment reads like a confirmation that this is happening with Clojure: > Leiningen, the older and still quite popular way > borkdude’s new project seems to be trying to bridge the gap by providing some pre-canned equivalents of popular Leiningen commands, but built on top of deps.edn. Instead of lein this is neil. Maybe the story will be different for Clojure and people really will converge on the official solution eventually, who knows

didibus 4y ago
I think in 2007, when Clojure first released, it wasn't common the way it is now that a language comes already with a full set of official tooling maintained alongside it. I feel this trend started later on. That said, it's also because Clojure is not its own runtime, so its actual tooling is the same as Java's. This is how it started, just expecting you'd use Maven as was standard in Java back then. Its the community that kind of decided they didn't like to use the Java tooling and on their own brought Clojars and Lein as replacement. So I think that's why at first there wasn't any, and later the core team thought, okay, well, if people want Clojure tooling and don't want to just Maven as maybe it was first intended, then they'd rather take it over and do it how they think is best. This is my interpretation of the history at least.
- brundolf 4y ago
  That makes sense, thanks for the context
casion 4y ago
Yes, there is a divide in the ecosystem for existing projects and knowledge, however new projects have a choice between two excellent, well documented and capable toolchains with sizable populations. I understand that as a beginner this is painful. You generally want to be told what to do with tooling, then ignore it for a while when you learn the language. As you mature as a developer in that ecosystem, the choices become a great benefit. It's true in Python as in C as in Common Lisp as in Clojure. I am a professional Clojure developer, and despite using Leiningen for many years I would say right now that I barely even know how to create a project or how to read a non-trivial project.clj. tools.deps on the other hand I feel confident with and believe it's one of the better systems out there. There are people who feel the opposite (in all ways), and I think that's _awesome_.