Fork me on GitHub
#leiningen
<
2018-07-02
>
gfredericks01:07:11

but if a plugin has middleware that adds to your dependencies collection, does it make a difference then?

rickmoynihan21:07:43

Hey… Just seen your questions about :middleware adding dependencies etc… FWIW I went through this recently when writing the lein-tools-deps plugin: https://github.com/RickMoynihan/lein-tools-deps Plugins can add :dependencies themselves, we do it with lein-tools-deps, though tools.deps typically fetches them and installs them into .m2 so leiningen won’t usually fetch them again (though I believe it would if it didn’t find). For reference - most leiningen tasks are implemented as plugins, and some add :dependencies too. e.g. lein repl: https://github.com/technomancy/leiningen/blob/master/src/leiningen/repl.clj#L199-L203 Note they define a profile internally which allows a user the ability to override the plugins deps if they need to specify a different version etc to resolve a conflict. Hope this helps.

gfredericks21:07:20

oh I forgot about the internal profile trick -- I wonder if that's the way to keep the deps out of prod

gfredericks21:07:29

e.g., if the profile only gets added for specific tasks

gfredericks21:07:51

I'm not sure that's doable if it's an existing task though, like repl or run

rickmoynihan23:07:34

yeah if it’s an existing task you might need to do something else… though you may with middleware be able to override their internal profile from your plugin… don’t know though.

danielcompton06:07:16

I’m not sure how good an idea it is for a plug-in to add dependencies when they haven’t been asked for, for this kind of reason

jonathanj09:07:54

If I run the lein-localrepo plugin via lein with-profile I get an error about a suppressed exit, flipping on the DEBUG envvar I found out it’s because lein-localrepo calls (main/exit 0) itself.

jonathanj09:07:29

Is there a way to fix this without modifying lein-localrepo itself?

jonathanj10:07:54

This seem like an issue with lein-localrepo, for completeness: https://github.com/kumarshantanu/lein-localrepo/issues/13

enn19:07:43

$ lein help install
Install jar and pom to the local repository; typically ~/.m2.
Does anyone know if there is more documentation on this somewhere? Specifically, what might cause “the local repository” to not be ~/.m2? It’s installing the jar to the project directory instead and I can’t figure out why.

mikerod19:07:48

there is a project prop called :local-repo, sounds like you may have it set to a non-default?

mikerod19:07:12

Do you have a ~/profiles.clj doing this perhaps, if not your project.clj of your current project

enn19:07:15

@mikerod I don’t have that set in either of the places I know to look:

$ grep local-repo project.clj
$ grep local-repo ~/.lein/profiles.clj
$

mikerod19:07:32

@enn what does lein prrint say for it

enn19:07:33

@mikerod weird, :local-repo is not in the list of properties output by pprint

mikerod19:07:51

@enn well, it is normal to install the project artifacts to /target of the current project (or whatever you have your output/target dir configured to)

mikerod19:07:09

But it should also be putting the artifacts in ~/.m2. Are you sure that is not what is happening?

enn19:07:19

maybe … is it also normal to put pom.xml in the project root? (not target)

enn19:07:48

It doesn’t appear to be installing in ~/.m2 anymore although it was last week. Now when I run lein install the old remains in ~/.m2.

enn19:07:49

I deleted the older install under ~/.m2 and ran lein install again and it was not replaced.

mikerod20:07:36

> maybe … is it also normal to put pom.xml in the project root? (not target) yes

mikerod20:07:52

is it a SNAPSHOT version

mikerod20:07:06

it’ll install with different timestamps each time then

mikerod20:07:18

if it is a fixed version, it won’t auto replace it I don’t think

enn21:07:13

it is a snapshot version

enn21:07:47

regardless of auto replace shouldn’t it have installed it under ~/.m2 after I deleted it?

danielcompton21:07:33

@enn can you share your whole project.clj?

enn21:07:44

ah, I think I figured it out. I knew it would be something stupid. I had added a namespace and was looking at the old un-namespaced jar under ~/.m2.