Fork me on GitHub
#tools-deps
<
2020-01-23
>
sveri10:01:46

Hi, is there a way to define an alias that extends an existing alias?

vlaaad10:01:16

no alias composition, as far as I know

sveri10:01:14

Ok, thank you 🙂

sam20:01:04

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.

alexmiller20:01:27

it can be a bit fiddly though, so when it doesn't work, come back here :)

sam21:01:55

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?

seancorfield21:01:35

@samwagg0583 Correct. t.d.a can only process deps.edn and pom.xml based git dependencies.

borkdude21:01:03

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 medley

avi02:01:34

I like this tip! Thanks!

seancorfield21:01:24

Yes, true, you can "force" :deps and it treats it as if deps.edn exists with {} as its contents.

sam21:01:16

Thanks everyone.

sam21:01:38

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.

sam21:01:08

I mean, I'd rather not have 2 different listings of deps like that. But it seems like an option.

seancorfield22:01:11

@samwagg0583 If the repo has dependencies, then adding a pom.xml file seems like a good compromise.

seancorfield22:01:41

Just bear in mind that if someone updates project.clj and forgets to update pom.xml you'll have inconsistent dependencies downstream.

seancorfield22:01:24

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...

seancorfield22:01:21

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.