Fork me on GitHub
#leiningen
<
2018-09-19
>
gfredericks13:09:04

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

jon32416:09:30

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

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

   :core          [{...}
                   :core-deps]
}
but I get (Warning: profile :core-deps not found.). My uberjar gets created but its missing all the dependencies defined in :core-deps. Any thoughts?

andy.fingerhut17:09:19

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

andy.fingerhut17:09:14

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.

andy.fingerhut17:09:15

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.

andy.fingerhut17:09:10

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.

jarvinenemil18:09:32

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

jon32418:09:15

Does uberjar work with composite profiles?

mikerod18:09:35

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

mikerod18:09:06

but uberjar should be fine with composite profiles

mikerod18:09:54

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

mikerod18:09:44

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

andy.fingerhut18:09:34

@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:

andy.fingerhut18:09:56

[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

andy.fingerhut18:09:17

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.

jon32419:09:50

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

andy.fingerhut19:09:02

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

mikerod19:09:26

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

mikerod19:09:48

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

jon32419:09:02

I believe so, it includes all the dependencies from :core-deps as well as the root dependencies, which is what I want

mikerod20:09:55

I know uberjar has some interesting behavior in terms of stripping away profiles that are considered to not be things you’d want to deploy

mikerod20:09:01

such as :test, :dev, :user

jon32420:09:50

Right, but is that all that’s stripped away?

mikerod20:09:02

I wonder if “core” is a clash

jon32420:09:02

Funny thing is I also tried this :core [:core-rest :core-deps] lein with-profile core uberjar And this way fails because it’s not using the dependencies from :core-deps

mikerod20:09:27

what do you mean it fails?

mikerod20:09:39

how does it behave differently? and what is in :core-rest in that situation?

mikerod20:09:06

I don’t like to jump directly to it without figuring out first, but you could add ^:leaky metadata to the profile

mikerod20:09:20

:core ^:leaky [{} :core-deps]

mikerod20:09:24

that may be what you are missing

mikerod20:09:39

or compose it into the default :uberjar profile that I believe lein has special casing for

mikerod20:09:50

:uberjar [:core {<etc>}]

mikerod20:09:14

These are the default ones [:base :system :user :provided :dev] by the way, so :core isn’t a clash

mikerod20:09:03

and of course, I messed up :leaky is the metadata (not :sticky) - will edit

jon32420:09:34

Unfortunately ^:leaky didnt change anything

jon32420:09:58

:uberjar [:core {<etc>}] for {<etc>} should I be able to stick in a profile?

jon32420:09:10

i.e. :uberjar [:core :core-deps]

mikerod20:09:04

yes, <etc> can be whatever is allowed in a composite profile

mikerod20:09:13

and :uberjar should be :leaky automatically

jon32420:09:26

What I was talking about with :core [:core-rest :core-deps] was that :core-rest would contain everything except the dependencies

:core-rest {:main        foo.core
               :aot          [foo.core]
               :uberjar-name "core.jar"
               :jvm-opts     ["-Xmx2g"]}

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

mikerod20:09:24

yeah, don’t see why that’d be aproblem

jon32420:09:28

And lein with-profile core uberjar would yield

Compiling foo.core
java.io.FileNotFoundException: Could not locate kinsky/client__init.class or kinsky/client.clj on classpath., compiling:(kafka.clj:1:1)
Exception in thread "main" java.io.FileNotFoundException: Could not locate kinsky/client__init.class or kinsky/client.clj on classpath., compiling:(kafka.clj:1:1)

mikerod20:09:52

I remember I had a weird issue with uberjar and how it profile merges/unmerges before

jon32420:09:53

kinsky here is in :core-deps

mikerod20:09:03

I think at one point, I had to put an empty map in my composite profile if everything else was keywords

mikerod20:09:14

:uberjar [:core-deps :core-rest {}]

mikerod20:09:34

wish I had notes on what I discovered then, because not sure how to find it

jon32420:09:57

:core [:core-rest :core-deps {}] gives

(Warning: profile :core-deps not found.)

mikerod20:09:16

well if you use anything other than :uberjar, need to make it :leaky

jon32420:09:03

:core ^:leaky [:core-rest :core-deps {}] same output as my above message

mikerod20:09:38

well I at least see I wrote this a long while back https://github.com/technomancy/leiningen/issues/2393

mikerod20:09:47

not sure if it was directly related thoug

jon32420:09:24

Yeah I was looking at that issue earlier

mikerod20:09:13

somehow that all related to my journey into uberjar and profile merging

mikerod20:09:46

looks relevant

mikerod20:09:56

the “fix” is interesting to me, I don’t see how it is connected - but could be

jon32420:09:20

Thanks for your help Mike, for now I think I’m just going to repeat myself

mikerod20:09:29

also, when you get a failure

mikerod20:09:32

do you know at what step?

mikerod20:09:52

perhaps add DEBUG=true lein with-profile core uberjar

jon32420:09:52

I dont follow

mikerod20:09:59

the uberjar has a few phases

mikerod20:09:14

it’d be nice to know which one of those throws the exception - but may not have enough logging to know

mikerod20:09:16

but perhaps

jon32420:09:08

Leiningen's classpath: :/usr/local/Cellar/leiningen/2.8.1/libexec/leiningen-2.8.1-standalone.jar
Applying task with-profile to [core uberjar]
Applying task uberjar to nil
Applying task javac to nil
Running javac with [@/var/folders/vx/lh15rktj52v0f2nn2fzn_c6h0000gn/T/.leiningen-cmdline2028878200747410550.tmp]
Applying task compile to nil
Compiling foo.core
java.io.FileNotFoundException: Could not locate kinsky/client__init.class or kinsky/client.clj on classpath., compiling:(kafka.clj:1:1)
Exception in thread "main" java.io.FileNotFoundException: Could not locate kinsky/client__init.class or kinsky/client.clj on classpath., compiling:(kafka.clj:1:1)

mikerod20:09:39

so fails in the compile task

mikerod20:09:41

good to know at least

mikerod20:09:45

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

mikerod20:09:56

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

mikerod20:09:07

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

mikerod20:09:24

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

andy.fingerhut20:09:52

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

andy.fingerhut20:09:47

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

mikerod20:09:08

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

mikerod20:09:19

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

mikerod20:09:30

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

mikerod20:09:41

especially for a snapshot (not a released) artifact

andy.fingerhut20:09:23

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

mikerod20:09:29

yeah, maybe try comparing

andy.fingerhut20:09:35

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:

andy.fingerhut20:09:47

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

mikerod20:09:16

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

mikerod20:09:31

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

andy.fingerhut20:09:46

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.

andy.fingerhut20:09:17

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

andy.fingerhut20:09:01

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

mikerod20:09:14

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

mikerod20:09:26

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

mikerod20:09:43

doesn’t seem like eastwood is doing anything particularly crazy

andy.fingerhut20:09:06

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

andy.fingerhut20:09:13

Still might be just me, though 🙂

mikerod20:09:21

> 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

mikerod20:09:34

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

mikerod20:09:59

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

mikerod20:09:03

when desperate for answers

andy.fingerhut20:09:54

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

mikerod20:09:24

I just git clone the leiningen repo

mikerod20:09:33

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

mikerod20:09:42

that’s the “plugin” part of it

andy.fingerhut20:09:44

using lein repl?

mikerod20:09:52

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

mikerod20:09:14

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

mikerod20:09:22

so in your case

mikerod20:09:43

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

mikerod20:09:51

since it is a pretty straightforward one

andy.fingerhut20:09:11

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?

mikerod20:09:23

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

mikerod20:09:47

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

mikerod20:09:02

it’s a meta-thing I guess hah

mikerod20:09:12

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

andy.fingerhut20:09:31

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

mikerod20:09:58

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

mikerod20:09:46

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

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

(classpath p)

mikerod20:09:00

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

andy.fingerhut20:09:15

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/

andy.fingerhut20:09:03

but thanks 🙂

mikerod20:09:30

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

andy.fingerhut20:09:58

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

andy.fingerhut20:09:12

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

mikerod20:09:14

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

mikerod20:09:48

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


mikerod20:09:09

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

mikerod20:09:24

so it seemed to pull from my snapshot install

andy.fingerhut20:09:51

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

andy.fingerhut20:09:27

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

mikerod20:09:44

oh cool, reacreated it

mikerod20:09:46

super weird

andy.fingerhut20:09:59

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

mikerod20:09:37

weird it runs on itself

mikerod20:09:41

should be no different really

andy.fingerhut20:09:45

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

andy.fingerhut20:09:10

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

andy.fingerhut20:09:34

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

mikerod20:09:36

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

mikerod20:09:52

and eastwood-version-string is “0.2.8”

mikerod20:09:58

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

andy.fingerhut20:09:58

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.

mikerod20:09:29

it uses a lib called leinjacker

mikerod20:09:54

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

slipset21:09:38

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

andy.fingerhut21:09:45

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

mikerod21:09:18

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")

mikerod21:09:23

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

andy.fingerhut21:09:56

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.

slipset21:09:22

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

slipset21:09:49

@andy.fingerhut no problem at all!

mikerod21:09:58

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

slipset21:09:06

I just happy to get the info

mikerod21:09:15

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

mikerod21:09:42

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

andy.fingerhut21:09:28

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.

slipset21:09:18

@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”

slipset21:09:33

D!mn autocorrect!

mikerod21:09:07

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

mikerod21:09:13

when I lein repl on the proejct

mikerod21:09:34

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

mikerod21:09:55

so I’m failing at even trying to dig hah

mikerod21:09:13

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

andy.fingerhut21:09:18

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.

slipset21:09:55

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

mikerod21:09:56

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

mikerod21:09:15

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

andy.fingerhut21:09:27

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?

mikerod21:09:11

haha, I didn’t solve anything, I don’t deserve/need a reward 😛

andy.fingerhut21:09:40

I thought you might say that. There needs to be a way to physically ship something to someone on Slack without having to know where they are 🙂

mikerod21:09:29

that is true

mikerod21:09:44

Slack needs a reward system I guess

mikerod21:09:04

but in this case, I don’t need a reward (but others do sometimes, so the system would be good)

slipset21:09:28

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

andy.fingerhut21:09:17

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

andy.fingerhut21:09:54

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.

andy.fingerhut21:09:08

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

andy.fingerhut21:09:36

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

mikerod21:09:02

ok, so sort of solved-ish some of it

mikerod21:09:15

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

mikerod21:09:31

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

mikerod21:09:22

so to workaround it

mikerod21:09:12

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

andy.fingerhut21:09:40

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

mikerod21:09:13

updated the issue

mikerod21:09:26

you have to have it in 2 places

mikerod21:09:31

:dependencies and :plugins

mikerod21:09:41

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

mikerod21:09:25

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

mikerod21:09:04

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

andy.fingerhut21:09:14

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

mikerod21:09:18

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

andy.fingerhut21:09:27

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

andy.fingerhut21:09:40

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.

andy.fingerhut21:09:01

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

slipset21:09:38

Thanks a lot @mikerod!

slipset21:09:22

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)

mikerod21:09:52

Yeah, maybe roll-own

mikerod21:09:55

would have to think about it

slipset21:09:59

Likewise, the other use of leinjacker in that file:

slipset21:09:14

eval-in-project could probably also be removed,

slipset21:09:31

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

slipset21:09:04

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

andy.fingerhut21:09:29

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

mikerod21:09:33

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

mikerod21:09:54

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

mikerod21:09:10

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

andy.fingerhut21:09:33

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.

andy.fingerhut21:09:31

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

slipset21:09:09

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

slipset21:09:26

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

andy.fingerhut21:09:00

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

andy.fingerhut21:09:54

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

mikerod21:09:19

drink emojis it is