What do Clojure deps.edn :deps keys mean?
up vote
2
down vote
favorite
Trying to use Clojure Deps and CLI, I was surprised to find out that the following all worked for using clojure.data.json.
Maven dependency:
{:deps {org.clojure/data.json {:mvn/version "0.2.6"}}}
Git dependency with same key:
{:deps {org.clojure/data.json {:git/url "https://github.com/clojure/data.json.git"
:sha "13e9d244678be7b235bb24a10310f9d147ea088d"}}}
Git dependency with random key:
{:deps {lol/this-works {:git/url "https://github.com/clojure/data.json.git"
:sha "13e9d244678be7b235bb24a10310f9d147ea088d"}}}
With Maven and Clojars dependencies, :deps keys identify the artifact. When using a git sha instead, the name doesn't seem to matter.
- What do Clojure deps.edn :deps keys mean?
- How should I choose my :deps keys?
Resources I've read but may contain what I'm after:
- Clojure Deps and CLI Guide
- Clojure Deps and CLI Reference
clojure dependencies
add a comment |
up vote
2
down vote
favorite
Trying to use Clojure Deps and CLI, I was surprised to find out that the following all worked for using clojure.data.json.
Maven dependency:
{:deps {org.clojure/data.json {:mvn/version "0.2.6"}}}
Git dependency with same key:
{:deps {org.clojure/data.json {:git/url "https://github.com/clojure/data.json.git"
:sha "13e9d244678be7b235bb24a10310f9d147ea088d"}}}
Git dependency with random key:
{:deps {lol/this-works {:git/url "https://github.com/clojure/data.json.git"
:sha "13e9d244678be7b235bb24a10310f9d147ea088d"}}}
With Maven and Clojars dependencies, :deps keys identify the artifact. When using a git sha instead, the name doesn't seem to matter.
- What do Clojure deps.edn :deps keys mean?
- How should I choose my :deps keys?
Resources I've read but may contain what I'm after:
- Clojure Deps and CLI Guide
- Clojure Deps and CLI Reference
clojure dependencies
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Trying to use Clojure Deps and CLI, I was surprised to find out that the following all worked for using clojure.data.json.
Maven dependency:
{:deps {org.clojure/data.json {:mvn/version "0.2.6"}}}
Git dependency with same key:
{:deps {org.clojure/data.json {:git/url "https://github.com/clojure/data.json.git"
:sha "13e9d244678be7b235bb24a10310f9d147ea088d"}}}
Git dependency with random key:
{:deps {lol/this-works {:git/url "https://github.com/clojure/data.json.git"
:sha "13e9d244678be7b235bb24a10310f9d147ea088d"}}}
With Maven and Clojars dependencies, :deps keys identify the artifact. When using a git sha instead, the name doesn't seem to matter.
- What do Clojure deps.edn :deps keys mean?
- How should I choose my :deps keys?
Resources I've read but may contain what I'm after:
- Clojure Deps and CLI Guide
- Clojure Deps and CLI Reference
clojure dependencies
Trying to use Clojure Deps and CLI, I was surprised to find out that the following all worked for using clojure.data.json.
Maven dependency:
{:deps {org.clojure/data.json {:mvn/version "0.2.6"}}}
Git dependency with same key:
{:deps {org.clojure/data.json {:git/url "https://github.com/clojure/data.json.git"
:sha "13e9d244678be7b235bb24a10310f9d147ea088d"}}}
Git dependency with random key:
{:deps {lol/this-works {:git/url "https://github.com/clojure/data.json.git"
:sha "13e9d244678be7b235bb24a10310f9d147ea088d"}}}
With Maven and Clojars dependencies, :deps keys identify the artifact. When using a git sha instead, the name doesn't seem to matter.
- What do Clojure deps.edn :deps keys mean?
- How should I choose my :deps keys?
Resources I've read but may contain what I'm after:
- Clojure Deps and CLI Guide
- Clojure Deps and CLI Reference
clojure dependencies
clojure dependencies
edited Nov 20 at 12:12
asked Nov 19 at 15:23
Teodor
400310
400310
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
It would seem that this is a result of how the git "extension" is handled in the tooling when compared to other "extensions" like maven. All the relevant code for this can be found here. I'll also make it clear that I haven't read this code in depth, and so my knowledge of this code therefore is not deep.
If you look at the way the lib
is treated in the maven extension for example, it appears that it is actually checking maven to see that the artifact exists by the name supplied, which you can see in more than one place, but also including in the multimethod definition of ext/canonicalize :mvn
In the git extension code, the lib
is given a different treatment, which you can see in the multimethod definition of ext/canonicalize :git
I don't want to get too deep into the realm of conjecture here, but I would guess that if this was an intentional design decision, it probably has something to do with the notion of the address of a git repo being the SoT for those kind of dependencies (even though the address/name of the repo can change... danger!), whereas in Maven names are registered first-class citizens.
And to try to more directly answer your two questions... What do the :deps
keys mean? The simple answer is it depends on what kind of dep it is! When using git, it can be whatever, and when using Maven for example it must reference a known package. How should I choose my dep keys? This has the danger of being subjective, however, I would recommend tending to use any dep that has a reliable immutable repository of packages behind it, and only when needed use a dep like github. This is because github dependencies can change their address/name, or simply vanish into thin air (deleted repository).
You've helped me see that I've tangled two very different questions here. (A) What do the keys mean mechanically, in the way that they are treated by tools.deps.alpha? (B) How should we reference dependencies? This was helpful to me. Thanks!
– Teodor
Nov 21 at 9:51
Hey no problem! Glad I was able to help :-)
– rdgd
Nov 27 at 20:01
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
It would seem that this is a result of how the git "extension" is handled in the tooling when compared to other "extensions" like maven. All the relevant code for this can be found here. I'll also make it clear that I haven't read this code in depth, and so my knowledge of this code therefore is not deep.
If you look at the way the lib
is treated in the maven extension for example, it appears that it is actually checking maven to see that the artifact exists by the name supplied, which you can see in more than one place, but also including in the multimethod definition of ext/canonicalize :mvn
In the git extension code, the lib
is given a different treatment, which you can see in the multimethod definition of ext/canonicalize :git
I don't want to get too deep into the realm of conjecture here, but I would guess that if this was an intentional design decision, it probably has something to do with the notion of the address of a git repo being the SoT for those kind of dependencies (even though the address/name of the repo can change... danger!), whereas in Maven names are registered first-class citizens.
And to try to more directly answer your two questions... What do the :deps
keys mean? The simple answer is it depends on what kind of dep it is! When using git, it can be whatever, and when using Maven for example it must reference a known package. How should I choose my dep keys? This has the danger of being subjective, however, I would recommend tending to use any dep that has a reliable immutable repository of packages behind it, and only when needed use a dep like github. This is because github dependencies can change their address/name, or simply vanish into thin air (deleted repository).
You've helped me see that I've tangled two very different questions here. (A) What do the keys mean mechanically, in the way that they are treated by tools.deps.alpha? (B) How should we reference dependencies? This was helpful to me. Thanks!
– Teodor
Nov 21 at 9:51
Hey no problem! Glad I was able to help :-)
– rdgd
Nov 27 at 20:01
add a comment |
up vote
2
down vote
accepted
It would seem that this is a result of how the git "extension" is handled in the tooling when compared to other "extensions" like maven. All the relevant code for this can be found here. I'll also make it clear that I haven't read this code in depth, and so my knowledge of this code therefore is not deep.
If you look at the way the lib
is treated in the maven extension for example, it appears that it is actually checking maven to see that the artifact exists by the name supplied, which you can see in more than one place, but also including in the multimethod definition of ext/canonicalize :mvn
In the git extension code, the lib
is given a different treatment, which you can see in the multimethod definition of ext/canonicalize :git
I don't want to get too deep into the realm of conjecture here, but I would guess that if this was an intentional design decision, it probably has something to do with the notion of the address of a git repo being the SoT for those kind of dependencies (even though the address/name of the repo can change... danger!), whereas in Maven names are registered first-class citizens.
And to try to more directly answer your two questions... What do the :deps
keys mean? The simple answer is it depends on what kind of dep it is! When using git, it can be whatever, and when using Maven for example it must reference a known package. How should I choose my dep keys? This has the danger of being subjective, however, I would recommend tending to use any dep that has a reliable immutable repository of packages behind it, and only when needed use a dep like github. This is because github dependencies can change their address/name, or simply vanish into thin air (deleted repository).
You've helped me see that I've tangled two very different questions here. (A) What do the keys mean mechanically, in the way that they are treated by tools.deps.alpha? (B) How should we reference dependencies? This was helpful to me. Thanks!
– Teodor
Nov 21 at 9:51
Hey no problem! Glad I was able to help :-)
– rdgd
Nov 27 at 20:01
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
It would seem that this is a result of how the git "extension" is handled in the tooling when compared to other "extensions" like maven. All the relevant code for this can be found here. I'll also make it clear that I haven't read this code in depth, and so my knowledge of this code therefore is not deep.
If you look at the way the lib
is treated in the maven extension for example, it appears that it is actually checking maven to see that the artifact exists by the name supplied, which you can see in more than one place, but also including in the multimethod definition of ext/canonicalize :mvn
In the git extension code, the lib
is given a different treatment, which you can see in the multimethod definition of ext/canonicalize :git
I don't want to get too deep into the realm of conjecture here, but I would guess that if this was an intentional design decision, it probably has something to do with the notion of the address of a git repo being the SoT for those kind of dependencies (even though the address/name of the repo can change... danger!), whereas in Maven names are registered first-class citizens.
And to try to more directly answer your two questions... What do the :deps
keys mean? The simple answer is it depends on what kind of dep it is! When using git, it can be whatever, and when using Maven for example it must reference a known package. How should I choose my dep keys? This has the danger of being subjective, however, I would recommend tending to use any dep that has a reliable immutable repository of packages behind it, and only when needed use a dep like github. This is because github dependencies can change their address/name, or simply vanish into thin air (deleted repository).
It would seem that this is a result of how the git "extension" is handled in the tooling when compared to other "extensions" like maven. All the relevant code for this can be found here. I'll also make it clear that I haven't read this code in depth, and so my knowledge of this code therefore is not deep.
If you look at the way the lib
is treated in the maven extension for example, it appears that it is actually checking maven to see that the artifact exists by the name supplied, which you can see in more than one place, but also including in the multimethod definition of ext/canonicalize :mvn
In the git extension code, the lib
is given a different treatment, which you can see in the multimethod definition of ext/canonicalize :git
I don't want to get too deep into the realm of conjecture here, but I would guess that if this was an intentional design decision, it probably has something to do with the notion of the address of a git repo being the SoT for those kind of dependencies (even though the address/name of the repo can change... danger!), whereas in Maven names are registered first-class citizens.
And to try to more directly answer your two questions... What do the :deps
keys mean? The simple answer is it depends on what kind of dep it is! When using git, it can be whatever, and when using Maven for example it must reference a known package. How should I choose my dep keys? This has the danger of being subjective, however, I would recommend tending to use any dep that has a reliable immutable repository of packages behind it, and only when needed use a dep like github. This is because github dependencies can change their address/name, or simply vanish into thin air (deleted repository).
answered Nov 20 at 17:54
rdgd
8722928
8722928
You've helped me see that I've tangled two very different questions here. (A) What do the keys mean mechanically, in the way that they are treated by tools.deps.alpha? (B) How should we reference dependencies? This was helpful to me. Thanks!
– Teodor
Nov 21 at 9:51
Hey no problem! Glad I was able to help :-)
– rdgd
Nov 27 at 20:01
add a comment |
You've helped me see that I've tangled two very different questions here. (A) What do the keys mean mechanically, in the way that they are treated by tools.deps.alpha? (B) How should we reference dependencies? This was helpful to me. Thanks!
– Teodor
Nov 21 at 9:51
Hey no problem! Glad I was able to help :-)
– rdgd
Nov 27 at 20:01
You've helped me see that I've tangled two very different questions here. (A) What do the keys mean mechanically, in the way that they are treated by tools.deps.alpha? (B) How should we reference dependencies? This was helpful to me. Thanks!
– Teodor
Nov 21 at 9:51
You've helped me see that I've tangled two very different questions here. (A) What do the keys mean mechanically, in the way that they are treated by tools.deps.alpha? (B) How should we reference dependencies? This was helpful to me. Thanks!
– Teodor
Nov 21 at 9:51
Hey no problem! Glad I was able to help :-)
– rdgd
Nov 27 at 20:01
Hey no problem! Glad I was able to help :-)
– rdgd
Nov 27 at 20:01
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53377746%2fwhat-do-clojure-deps-edn-deps-keys-mean%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown