is there any difference between putting a plugin at the top level vs in the dev profile?

I’m trying to do lein with-profile core,core-deps uberjar where:

:profiles {
   :core-deps      {:dependencies [...]}

   :core          [{...}
                   :core-deps]
}

I think the issue I'm looking at (as a background task) is specific to the Eastwood project, or something about the way its JAR files are created and/or deployed to Clojars, but I was looking for ideas on what might be going weird here. https://github.com/jonase/eastwood/issues/284

With older Eastwood source versions, I could 'lein install' in its source directory, edit that version into my ~/.lein/profiles.clj file, change to another lein project directory and run 'lein eastwood' and it would use that new local version.

Now when I try that, e.g. with version '0.2.10-SNAPSHOT' in my profiles.clj file, the command 'lein eastwood' in a different project directory will download Eastwood 0.2.8 from Clojars, and I believe it then runs that version.

I tried setting the DEBUG env variable, and got a few additional messages from lein, but nothing that seemed to give any explanation for why it would download that other Eastwood version from Clojars when I would guess it did not need to do so.

Guys I have two leiningen projects (two different leiningen run). One UI project and one "Back-end" project. Is this bad practise? I am currently getting issues with Figwheel (Ring Session keeps on reseting). If I call my API from insomnia the Ring session works fine though

Does uberjar work with composite profiles?

@jon324 you shouldn’t need to specify core-deps to with-profile since core is a composite profile already

but uberjar should be fine with composite profiles

are there any :dependencies specified in the other parts of the :core profile?

@andy.fingerhut what else is in your .m2 directory under the 0.2.10-SNAPSHOT directory for the jonase/eastwood artifact?

@mikerod If I delete my /.m2 and /.lein/profiles.clj, git clone the latest Eastwood source repo, cd into it, run lein install, then cd ~/.m2/repository/jonase/eastwood ; find . -ls I see this output:

[11:55:31] $ find . -ls
   400485      4 drwxr-xr-x   3 jafinger jafinger     4096 Sep 19 11:54 .
   400486      4 drwxr-xr-x   2 jafinger jafinger     4096 Sep 19 11:54 ./0.3.1-SNAPSHOT
   400489      4 -rw-r--r--   1 jafinger jafinger     3854 Sep 19 11:54 ./0.3.1-SNAPSHOT/eastwood-0.3.1-SNAPSHOT.pom
   400488      4 -rw-r--r--   1 jafinger jafinger      193 Sep 19 11:54 ./0.3.1-SNAPSHOT/_remote.repositories
   400487    272 -rw-r--r--   1 jafinger jafinger   275947 Sep 19 11:54 ./0.3.1-SNAPSHOT/eastwood-0.3.1-SNAPSHOT.jar
   400490      4 -rw-r--r--   1 jafinger jafinger      700 Sep 19 11:54 ./0.3.1-SNAPSHOT/maven-metadata-local.xml
   400491      4 -rw-r--r--   1 jafinger jafinger      274 Sep 19 11:54 ./maven-metadata-local.xml

Actually to get that I did hand-edit Eastwood's defproject version from 0.2.10-SNAPSHOT to 0.3.1-SNAPSHOT, as an experiment to see if it changed the behavior.

@mikerod there aren’t any more dependencies defined in :core, also when i tried lein with-profile core uberjar I got the same exact issue.

If instead I delete my ~/.m2, and git checkout the Eastwood source code from when it was 0.2.6-SNAPSHOT (git sha 53e48f34e2eafe25d742c8f3e6a711889cffa1c0), do lein install on that, edit my profiles.clj to use that version, change to a fresh lein project and run lein eastwood, it doesn't download Eastwood 0.2.8, and it uses 0.2.6-SNAPSHOT like I expected it would

@andy.fingerhut yeah, wondering if something is different about how it is installing in .m2, but weird

@jon324 does lein with-profile core deps :tree give what you expect for deps?

@andy.fingerhut that’s annoying. I can’t think of why it wouldn’t try to pick up a snapshot dep…

and especially how it may try to take a release version that you don’t even have specified

seems like something must be messed up in what is installed in .m2 or something

Also, I don’t work on the eastwood project at all, so no insight there, was just troubleshooting from a Maven/lein perspective

Probably is something unusual that eastwood is putting into ~/.m2 with most recent code, because it doesn't behave this way with a several-month-old version

I guess there is no easily turned on more detailed debug/log output in Leiningen for how it resolves dependencies?

so you could check out what is in /0.3.1-SNAPSHOT/maven-metadata-local.xml

and in /0.3.1-SNAPSHOT/_remote.repositories to see if you see anything fishy

but I really don’t see what could be done that is messing it up in the way you describe

especially for a snapshot (not a released) artifact

Not sure what is normal vs. odd there yet, but will take a look at an older works-as-expected local snapshot install, vs. latest weird-behavior local snapshot install

yeah, maybe try comparing

The newer weird version has the following additional section in its eastwood-0.2.10-SNAPSHOT.pom file, but not sure if that is a red flag or not:

!     <plugins>
!       <plugin>
!         <groupId>org.codehaus.mojo</groupId>
!         <artifactId>build-helper-maven-plugin</artifactId>
!         <version>1.7</version>
!         <executions>
!           <execution>
!             <id>add-source</id>
!             <phase>generate-sources</phase>
!             <goals>
!               <goal>add-source</goal>
!             </goals>
!             <configuration>
!               <sources>
!                 <source>copied-deps</source>
!               </sources>
!             </configuration>
!           </execution>
!         </executions>
!       </plugin>
!     </plugins>

I saw that was done in order to run eastwood on itself

I don’t see how it’d cause the problem you are having though 😞

Except for that, almost all I see different is the JAR (of course, but I haven't compared their full unzip'd contents yet), a few version numbers with expected differences between them, and the addition of a resources directory in addition to the previously-existing resource directory.

and some hex string under an XML tag <scm> that is probably for Clojars, or git, or something like that.

Thanks for the suggestions, by the way. You must get the weirdest off-the-wall questions about odd Leiningen behavior sometimes 🙂

@andy.fingerhut I probably need to try out what you are doing and see if it is just happening on your machine hah

but yeah, if the versions all look right in maven, I can’t think of anything

doesn’t seem like eastwood is doing anything particularly crazy

I can reproduce starting from empty /.m2 and no /.lein/profiles.clj on a Mac, and an Ubuntu 18.04 Linux machine

Still might be just me, though 🙂

> You must get the weirdest off-the-wall questions about odd Leiningen behavior sometimes I don’t work on lein though. I’ve just done a lot of messing around with it and trying to get it to bend to my will at times, so I try to answer questions on here when it seems like something I may have had some past insight into hah

Yeah, sounds like you did a pretty clean-slate setup

sometimes I go a bit more crazy with things and start lein in a REPL and go through it step-by-step

when desperate for answers

I've never started lein in a REPL before. Are there instructions somewhere for doing that?

I just git clone the leiningen repo

then start a REPL from it’s top-level project.clj

that’s the “plugin” part of it

using lein repl?

but it’ll have the rest of lein core on the classpath to mess around with

yeah, lein repl or whatever you like (e.g. I use cider and cider-jack-in is fine via lein too)

so in your case

I may navigate to the (in-ns 'leiningen.deps) ns

since it is a pretty straightforward one

So the "outer" lein repl is the standard unmodified one, typically, and the one you are starting up inside the REPL should use any local modifications to the source in your copy of the git repo?

but actually, think it really comes down to leiningen.classpath, so never mind deps, I’d go there

oh yes, the lein repl you start is from your installed lein

it’s a meta-thing I guess hah

but when you mess with the lein source stuff, it’s just like messing with any other project

Just if I add any debug print statements to my copy of lein source, I'd like to know which one is doing it.

you typically need the function leiningen.core.project/read then you can run the plugin fn’s like leiningen.classpath/classpath

e.g.

(in-ns 'leiningen.classpath)
(require [leiningen.core.project :as project])

(def p (project/read "path/to/project.clj"))

(classpath p)

but you can do whatever println or whatever debugging you want from there

It is entirely my fault if it goes this way, but I think you may be teaching me how to get from state "6 hours" to "10 hours" in this sequence: https://xkcd.com/349/

but thanks 🙂

Maybe I can find time to recreate your thing and mess with it

This is slavery wages, but if you figure it out, I'll buy you your beverage of choice up to $50.

Just remember the "slavery" part if you start going from "10 hours" to "24 hours" yourself

hah

ok, bad news for you though. I didn’t recreate your problem

I did this:

git clone <eastwood repo>
cd eastwood
lein install
;; Checked my `.m2` to see the version "0.2.10-SNAPSHOT" was installed

;; Add to `.lein/profiles.clj` the `[:user :plugins]` `[jonase/eastwood "0.2.10-SNAPSHOT"]`

;; Called eastwood on itself just to see
lein eastwood

My output running lein eastwood shows == Eastwood 0.2.10-SNAPSHOT Clojure 1.8.0 JVM 1.8.0_112

so it seemed to pull from my snapshot install

Please try creating a new lein project and running lein eastwood inside of it.

will do

with 0.2.10-SNAPSHOT in your ~/.lein/profiles.clj :user :plugins key

oh cool, reacreated it

super weird

I believe running eastwood on itself is fine. You don't even need to do lein install first -- it uses the local source

weird it runs on itself

should be no different really

It is using the locally installed version on any other project as a lein plugin that gives the weird behavior, and only with fairly recent versions of Eastwood (I haven't done git bisect).

But shouldn't it? I may have a wrong mental model, but even if you don't do lein install, it works, using any local source modifications in that git copy

'it works' meaning 'lein eastwood uses local source code when run from root of eastwood project'

well it does this

(leval/eval-in-project
         (add-if-missing project ['jonase/eastwood eastwood-version-string])
         `(eastwood.versioncheck/run-eastwood '~opts)
         '(require 'eastwood.versioncheck))

and eastwood-version-string is “0.2.8”

so that explains where that fallback behavior is coming from at least

I believe there have been changes in that startup code in the last few months. @slipset has been working to change the way Eastwood stores its own version inside of itself, in ways I haven't tried to grok yet.

it uses a lib called leinjacker

there is a fn called leinjacker.deps/add-if-missing that is apparently deciding that jonase/eastwood is missing as a dependency

Leinjacker has been there for a long time, but I’ve screwed up the versioning part.

leinjacker isn't new in Eastwood, but perhaps the parameters it is being passed are different than in past versions.

it also looks like it didn’t bump the version string in the “0.2.9” release, which may have just been missed (def eastwood-version-string "0.2.8")

but I don’t see how this has any recent changes that would have caused this to be a new problem

Sorry @slipset if I bugged you while at a conference or other more interesting things. Is this maybe old news for you? Sorry to bug you about it if so.

Which is part of what I wanted to solve. For every release of Eastwood the version had to be updated in about three places, and then once released, bumped to whatever-version-SNAPSHOT

@andy.fingerhut no problem at all!

add-if-missing project ['jonase/eastwood eastwood-version-string]) I don’t get why it is added

I just happy to get the info

if it is in the [:user :profiles], it should be in the project :dependencies at this point

I’ve tried lein with-profile +user eastwood to make sure that profile is merged on too (even though it is a default)

The use of leinjacker in whatever way it is doing probably hasn't changed since I inherited Eastwood code and started hacking on it. If it seemed to work, I left it as is.

@mikerod if you think this code is wrong or superfluous, I’d be more than happy with an issue, a PR, or just an explanation. I’m no Elin expert, and as @andy.fingerhut says, it’s been that way “forever”

D!mn autocorrect!

😛

I also just realized in the REPL I cannot load the namespace (require 'leiningen.eastwood)

when I lein repl on the proejct

eastwood.copieddeps.dep6.leinjacker.utils fails to compile due to this fn

(defn lein-home
  "Returns the leiningen home directory (typically ~/.lein/). This function
   abstracts away the differences in calling the leiningen-home function between
   Leiningen 1.x and 2.x."
  []
  ((try-resolve-any
    'leiningen.util.paths/leiningen-home   ;; lein1
    'leiningen.core.user/leiningen-home)))

so I’m failing at even trying to dig hah

oh, ;; :eval-in-leiningen true is commented

There may definitely be better ways for Eastwood to interact with Leiningen. I did confirm that that add-if-missing-project has been there since 2014 at least.

@mikerod thanks for trying. It’s late here in CET, but I’ll have a look tomorrow. Hackathon at work, so I should be able to spend some time on this.

I don’t immediately see any problem with add-if-missing-project, it just appears to be what is happening - it is being added even when we don’t think it is missing

@slipset no problem. I may look a bit more at it in a bit too.

OK, @mikerod, I think you've earned that beverage already, even if you think you haven't. What city in the world are you nearest to, or in?

I’d really appreciate it if you could file an issue outlining your problems, and I’ll see what I can do.

The behavior has an issue, but no description yet of why it happens, here: https://github.com/jonase/eastwood/issues/284

I can change the name of the issue to something like "recent Eastwood versions always pull in version 0.2.8" if that is clearer.

and anyone can toss in a comment there if they have something to add.

I've just added a comment linking to the source lines that @mikerod pointed out.

ok, so sort of solved-ish some of it

add-if-missing only checks if jonase/eastwood is in the (:dependencies project)

However, I think typically you put it in the :plugins of the project

so to workaround it

If I put in my .lein/profiles.clj an extra [:user :dependencies] of [jonase/eastwood "0.2.10-SNAPSHOT"], then lein eastwood will use the snapshot configured as expected

I tried that in my .lein/profiles.clj, and then tried lein eastwood in a new lein project, and it said "'eastwood' is not a task. See 'lein help'."

updated the issue

thx

you have to have it in 2 places

:dependencies and :plugins

did you remove it from :plugins when you got that error?

yes

:plugins is how lein knows to load it and knows it has tasks it can run etc.

but to thwart add-if-missing from adding the hard-wired version, you also need it in :dependencies

OK, also working for me when I have it in both [:user :plugins] and [:user :dependencies] of my ~/.lein/profiles.clj. Cool!

the fix is probably for add-if-missing (or something else) to respect it being found in :plugins

Understood that this is a workaround, and the real fix is to change Eastwood source code

Indeed

Any recommendations you have on better ways to do that, like the potential change you suggested for add-if-missing, would be cool to have in a brief comment on the issue, too. No need to write the code for us or anything, just a lead.

But don't be surprised if we ask follow-up questions 🙂

Thanks a lot @mikerod!

add-if-missing isn’t exactly rocket-surgery, https://github.com/sattvik/leinjacker/blob/51f8b79ffb169550fd1d89a2d49479455f0b5f9c/src/leinjacker/deps.clj#L52 so we might just consider rolling our own (and maybe getting rid of a dependency)

Yeah, maybe roll-own

would have to think about it

Likewise, the other use of leinjacker in that file:

eval-in-project could probably also be removed,

since it seems to just offer compatability between lein 1.x and 2.x

And I would suppose that it’s kind of safe to drop compatability for 1.x at this day and age?

[ ... checks date of copy of lein-1.7.1 still in his ~/bin directory ... 2012 ... move on ... ]

I haven’t actually looked at why eval-in-project is there, but I would think that supporting 1.x is probably unnecessary nowadays

but maybe that is something you make a note on a changelog or something if eastwood does drop the support

but I think many plugins don’t continue to try to please 1.x anymore

The README explicitly says it expects Lein 2.4 or later for a few years now. For what reason I don't recall right now.

Actually, it doesn't say 'required', just 'most tested with'. But changing that to require at this date seems reasonable.

A great, I guess that’s another Github issue then 🙂

Anyways, way past my bedtime now. Thanks for all the help!

Yes, thanks much for the discovery of bugs and better ways of doing things.

🍻

[ So far, the only way Slack supports for delivering beverages to others. ]

drink emojis it is