This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-23
Channels
- # aleph (14)
- # announcements (2)
- # babashka (8)
- # bangalore-clj (2)
- # beginners (66)
- # calva (8)
- # cider (1)
- # clj-kondo (24)
- # cljdoc (3)
- # cljs-dev (3)
- # cljsrn (2)
- # clojure (197)
- # clojure-europe (1)
- # clojure-india (5)
- # clojure-italy (4)
- # clojure-nl (27)
- # clojure-uk (18)
- # clojurescript (56)
- # code-reviews (19)
- # core-async (86)
- # cursive (16)
- # data-science (1)
- # datomic (16)
- # docker (3)
- # events (1)
- # fulcro (101)
- # graalvm (7)
- # graphql (16)
- # jobs (1)
- # jobs-discuss (6)
- # kaocha (4)
- # luminus (1)
- # off-topic (93)
- # onyx (3)
- # pathom (9)
- # planck (2)
- # re-frame (8)
- # reagent (3)
- # reitit (3)
- # remote-jobs (3)
- # shadow-cljs (21)
- # test-check (3)
- # tools-deps (21)
- # vim (16)
Are private git repos supported in deps.edn? The documentation says public and private are supported, but I'm not sure how to provide credentials for private and I can't find any instructions.
Nvm, I think I found documentation here: https://clojure.org/reference/deps_and_cli#_procurers.
yes and yes
it can be a bit fiddly though, so when it doesn't work, come back here :)
I got the private repo part to work, but got this error:
Error building classpath. Manifest type not detected when finding deps for provider-data-pipeline/provider-data-pipeline
which is apparently due to the fact that that the target repo is using leiningen for dependency management instead of deps.edn. Is that right?@samwagg0583 Correct. t.d.a can only process deps.edn
and pom.xml
based git dependencies.
if it's a dependency that only has sources and no other deps in its project.clj you can declare a manifest type:
Optional key :deps/manifest
Specifies the project manifest type
Default is to auto-detect the project type (currently either :deps or :pom)
This works for e.g. libs like medleyYes, true, you can "force" :deps
and it treats it as if deps.edn
exists with {}
as its contents.
What about using lein pom
to generate a pom and committing that to the target git repo? I do have control over the target, but I might not be able to convert it to deps.edn, at least in the short term. Curious if you guys have heard of anyone using that pattern and how it's worked out.
I mean, I'd rather not have 2 different listings of deps like that. But it seems like an option.
@samwagg0583 If the repo has dependencies, then adding a pom.xml
file seems like a good compromise.
Just bear in mind that if someone updates project.clj
and forgets to update pom.xml
you'll have inconsistent dependencies downstream.
Another alternative would be to put the basic dependencies from project.clj
into deps.edn
in that repo and use a plugin to pull them in from that file...
https://github.com/RickMoynihan/lein-tools-deps lets you do that
So then deps.edn
would be the "system of record" for the primary dependencies and both the Lein project and downstream consumers via git will see the same file, same deps.