when i run a Clojure repl i see that error:

❯ clj
Clojure 1.11.1
user=> (ns notion-api.api
  (:require
    ["@notionhq/client" :refer (Client)]))
Syntax error macroexpanding clojure.core/ns at (REPL:1:1).
((:require ["@notionhq/client" :refer (Client)])) - failed: Extra input spec: :clojure.core.specs.alpha/ns-form
user=>

❯ clj -A:cljs -M -m cljs.main -re node -r
ClojureScript 1.10.773
cljs.user=> (ns notion-api.api
  (:require
    ["@notionhq/client" :refer (Client)]))
Unexpected error (ExceptionInfo) compiling at (REPL:1).
No such namespace: @notionhq/client, could not locate _CIRCA_notionhq_SLASH_client.cljs, _CIRCA_notionhq_SLASH_client.cljc, or JavaScript source providing "@notionhq/client" (Please check that namespaces with dashes use underscores in the ClojureScript file name) in file <cljs repl>
notion-api.api=>

and in a shadow node repl:

❯ npx shadow-cljs node-repl
shadow-cljs - config: /private/tmp/wut/shadow-cljs.edn
[2022-11-18 23:23:51.747 - WARNING] TCP Port 9630 in use.
shadow-cljs - server version: 2.20.12 running at 
shadow-cljs - nREPL server started on port 50590
cljs.user=> shadow-cljs - #4 ready!
cljs.user=> (ns notion-api.api
  (:require
    ["@notionhq/client" :refer (Client)]))
SHADOW import error /private/tmp/wut/.shadow-cljs/builds/node-repl/dev/out/cljs-runtime/shadow.js.shim.module$$notionhq$client.js

Execution error (Error) at (<cljs repl>:1).
Cannot find module '@notionhq/client'
Require stack:
- /private/tmp/wut/[stdin]
:repl/exception!
cljs.user=>

oh 😅 yeah that was the problem. I connected to shadow-cljs with conjure but didn't actually select the build so I remained in the clojure repl. Thank you so much!

ring defines an interface, a format for http requests and responses as clojure data

There are many adapters that take a given http server and wires it up to speak ring

ah so in ruby-terms ring is the rails and http-kit is the puma ?

No

Ring is like maybe rack

ah sure

and reitit is like rails routes

so I need both ring and http-kit, right?

Ring + some server... Ring comes with Jetty 9 built-in. http-kit is a separate server you can use with Ring.

At work we used the default (Jetty 9) adapter for years but recently we wanted to add WebSocket support so we switched to https://github.com/sunng87/ring-jetty9-adapter which is Jetty 11 (despite its name!).

@U04V70XH6 why dont you use http-kit then if you need websockets?

is it worse for you?

reitit is a routing library. Compojure is probably the oldest, most widely-used routing library. We mostly use Compojure at work except for one app that uses Bidi. If we were starting over, we'd probably consider reitit, but you kinda have to buy into a bunch of metosin stuff and we don't need all of it.

We actually used http-kit for a while but New Relic (monitoring service) has very poor support for it, so we switched (back) to Jetty 9.

what is metosin stuff ? 😄

We added WebSocket support ourselves to the Jetty 9 adapter (built into Ring) and that was a pain, hence the switch to the sunng adapter (and Jetty 11).

https://github.com/metosin -- lots of well-designed, high-performance libraries (but we generally prefer older, simpler, and closer-to-Clojure-core stuff, e.g., Spec over Malli).

Clojure is very much focused on "composable libraries" rather than frameworks (like Rails), so it's very much a mix'n'match and choose your own journey kind of thing.

I'll answer your second question in a separate thread...

Thanks a lot Sean

If you want to look at a reasonably simple complete web app as a guide: https://github.com/seancorfield/usermanager-example/ -- that uses Compojure for routing and Component to manage stateful services etc, but the README links to a variant that uses reitit for routing and Integrant for stateful services. Some people find that a helpful repo to start learning about Clojure web apps from.

in my current project i use • reitit for routing • http-kit for serving http with the ring spec as the common interface

> with the ring spec as the common interface what do you mean?

the https://github.com/ring-clojure/ring-spec is that a request is a map of the shape

{:remote-addr "127.0.0.1"
 :uri "/"
 :headers {"content-type" "text/html"}
 :body nil ;; some InputStream
 ;; and a few more fields
 }

{:status 200
 :body "hello, world"
 :headers {"content-type" "text/plain"}}

["/"
 {:get {:handler (fn root-handler [request]
                   (if (= (:remote-addr request) "127.0.0.1")
                      {:status 200 :body "hello, myself"}
                      {:status 403 :body "this page is just for myself"}))}}]

ah I see @UAEH11THP thanks mate

ring as a library provides a lot of things. it has default middlewares (that parse query parameters or handle uploads for example) and a jetty-based http server so you can use it as a whole-fledged solution. many people prefer using other server libraries such as http-kit or aleph for various reasons. but the common "interface" is the ring standard

do you know, someone uses ring with jetty inside on production with high-load?

i think that's what Sean mentioned above https://clojurians.slack.com/archives/C053AK3F9/p1668836538057579?thread_ts=1668835710.601159&cid=C053AK3F9

if you're looking for a full packaged experience with routing and all, check out https://luminusweb.com/, https://kit-clj.github.io/ or https://github.com/AppsFlyer/donkey

@UAEH11THP yeah already checked out. But the current goal is learn from scratch for good experience

enjoy the ride

Ring/Jetty powers almost our entire online dating platform: 40 sites, a dozen languages, thousands of concurrent users 24x7. It's not Twitter-scale of course but Ring/Jetty has been rock solid for us. As was http-kit - we only stopped using that because of poor support in New Relic (Jetty is fully supported).

Leiningen is the oldest and most well-established "run/test/build" tool for Clojure. Boot was popular for a while but hardly anyone uses it now. Clojure CLI / deps.edn is the "official" approach.

At work, we started with Leiningen back in 2010 because it was the only real choice. We switched to Boot in 2015 and to the new CLI in 2018. The core team have since released tools.build which allows for arbitrarily complex dev/test/build workflows and we use that heavily at work.

@U04BRV8JQKE to get started with the CLI, you can just create deps.edn with whatever :deps you need and a src folder containing your code. No need for clj-new really.

Some history: lein new <name> <template> creates a fully-fledged project based on the template. lein new <name> app creates a basic application skeleton with no dependencies. When we switched to Boot, there was no equivalent so I wrote boot-new based on lein-new. When we switched to the CLI, there was no equivalent so I wrote clj-new based on boot-new 🙂 Later on, I wrote deps-new which is based around tools.build. It lets you create your own templates in a declarative way (using EDN files) but can also be customized with code in the template if needed. It's intended to be fairly minimal but some people have published templates that work with it. It supports lib, app, template, scratch, etc. clj-new can build projects from Leiningen templates (like lein-new), Boot templates (like boot-new), or Clojure templates. They're all pretty similar, but it gives you the widest range of choices of templates to start from. However, Leiningen templates tend to produce Leiningen projects, Boot templates tend to produce Boot projects. I.e., not Clojure CLI / deps.edn projects.

What's "nice" about clj-new/`deps-new` for starting a CLI project is that what they generate has a test runner and can build/deploy JAR files so it eliminates a lot of basic boilerplate in simple projects that you intend to publish or deploy. But for "pet projects" that you're using to learn/experiment with, you might be better off just following the official http://clojure.org docs to create your own CLI / deps.edn project from scratch.

A lot of books/tutorials still refer to Leiningen but I generally recommend beginners learn the CLI and deps.edn since it's the official tooling from the core team.

thank you a lot again 🙂 going to dive deeper in your text now

So I definitely need to start to use CLI to generate first pet projects to learn it from scratch. In future I can go to other tools like lein/clj-new etc

One of the coolest features (imo), if you plan to distribute something is making the uberjar, which is one of those things that may be an interesting curiosity to learn how to set up from scratch, but I prefer getting it for free with lein or clj-new - same deal for other repo setups - I find it easier to use a scaffolding tool and start working on my clojure changes and program (which is likely not in the vein of writing custom build tooling, so the knowledge gain in doing it from scratch tends to be minimal for real world usage)

Starting with a bare deps.edn and nothing in it is a little of a head scratcher - "Oh, what keys do I need to add in here to add some external dependencies" - compared to having a reference with 1 or 2 already there, that you just copy+adjust (and then go back and read the intro guide when you need to diverge a bit)

interesting opinion. But I this its better to go through official clojure CLI guide where bare deps.edn used as a first step into clojure projects

anyway I will learn lein/clj-new and other tools too 🙂

Understanding is good, I don't think there is anything to learn on the template tools though - its a single CLI command for the most part - then you end up with a ~5 to 10 file project (each very small) you can bounce around and see how the clojure namespaces are setup/defined, the test file tests the src dir etc. clojure -Tclj-new app :name yourname/yourproject for instance - the most confusing part is knowing how to invoke commands in the generated deps.edn (which probably would be more clear reading the tutorial as you suggest 😄 )

That's one thing I miss, lein as I recall made a nice Makefile - I love that unified interface to just type make test on any language I work in (I work in a ton of different ones) - not try to remember - Oh, do I run clj -T:build test for this repo? Do I run npm run test in this other one? what was that rake command for ruby test? or pytest on python... - nah, gimme make test anyday 😆

yeah, I love "make" too!

@U96DD8U80 I don't remember lein ever producing a Makefile but perhaps that was some specific template you used to create Leiningen projects? As regards "the most confusing part is knowing how to invoke commands in the generated deps.edn" -- feel free to create GH issues against clj-new or deps-new to highlight improvements in the docs and/or generated projects. I thought the generated README files provided all of the necessary instructions on how to invoke all the commands but I'd be happy to improve all of that if you have specifics.

@U04BRV8JQKE My day-to-day collection of tools and aliases is published here https://github.com/seancorfield/dot-clojure (and my VS Code/Calva/Joyride/Portal setup is here https://github.com/seancorfield/vscode-calva-setup if you're using any of that tooling stack). Just to show what's possible/available.

@U04V70XH6 the docs are great 🙂 - it's just my memory that isn't - when shuffling between hundreds of repos and tens of different languages, having one command for all is a smaller mental leap than many options and (or peeking at a readme first) - you may be right, perhaps the Makefile was my own addition or belonged to a template I used :thinking_face: - appreciate your work on clj/deps-new!

I personally used Leiningen when I started out, but I have trouble recommending deps.edn (or tools.build) at all because the documentation feels very incomplete. I've often had to go on askclojure to learn information that is otherwise not present in documentation and references, or it's not easy to infer such info from the documentation. Then there's minor annoyances like uberjars being a super complicated process. There's just a bunch of moving parts in a build.clj file, and for deps.edn there is no easy equivalent to things like leiningen's :init-ns . I've also never been a fan of the Clojure CLI because the flags are cryptic and I never remember what A, M, T, X, etc. even mean and I have to search them up every time. Note I am very biased since I do not like terminals in general and I did start with Leiningen then come to deps.edn, possibly with the wrong expectations.

With that said, leiningen isn't perfect either. You'll always be making some trade-off by choosing a particular tool. One thing I like about deps.edn is that you will have exactly one Clojure process, hence one JVM per project. With leiningen, you have an entire JVM for lein itself, then a JVM for your project.

> I never remember what A, M, T, X, etc. even mean Main. Tool. eXec. A is the odd one out since it's a synonym for M at the moment but will eventually mean "start a REPL" (which I think they should have expanded R to do).

I enjoy the more modern POSIX standards/flag handling, where they tend to have both a long flag (`--version`) and a short flag (`-v`) - it'd be a nice built-in to have -M and --main as well as -T and --tool - but it is a bit of a minor thing

tree-seq + filter + count

ah interesting, thanks!

This is the current version now:

(defn count-pair
  [data k v]
  (->> data
       (tree-seq #(or (map? %) (vector? %)) seq)
       (filter #(and (map-entry? %) (= k (key %)) (= v (val %))))
       (count)))

Try also this:

(defn count-pair
  [data k v]
  (->> data
       (tree-seq #(or (map? %) (vector? %)) seq)
       (filter #(and (map-entry? %) (= % [k v])))
       count))

nice! yeah tried that first then thought why not short even faster with the separate checks 😛

And I also think that filter row can be written as: (filter (every-pred map-entry? #(= % [k v]))) (but I'm not sure which way is preferred)

feels like one more processing step than before?

i guess at thins point its quite the nitpicking 😅

i was thinking to write the tree-seq as (tree-seq seq seq) but not sure if thats worse? creates more unnecessary Seqs?

ah no, this would fail with the terminal values

If you are fascinated by Clojure tooling, deps.edn. If you just want to write code, lein. Lein is friendlier.

@U0PUGPSFR so if I apply what I hear from your direction looks lein goes better, need to get the problem solved, not priority all the elegance. Thanks!

Opinions on that may differ :)

Getting up and running with https://github.com/seancorfield/deps-new is just as easy.

Given that you can run myscript.clj directly with the clojure CLI command, without deps.edn if you have no external dependencies, and can then add deps.edn and move to the src/`test` structure as and when you need it, my advice is always: start with the Clojure CLI (and deps.edn) -- it is well-maintained, well-designed, and well-documented by the core team on the official Clojure site http://clojure.org Except for helping a beginner with a problem from a tutorial or book that still uses Leiningen, I haven't used lein for many years at this point (at work we switched from lein to boot in 2015, then to the CLI in 2018).

I suggest the tooling for a hobby project only matters if at least some of the reason to do the project is to learn the tooling. The Clojure code for the project will be the same regardless Use tooling you are familiar with. ( unless you specifically want to learn a new tool). If not familiar with any of the tooling I would recommend using the Clojure CLI ( deps.edn).

deps.edn works well with clojure cli, has lots of documentation, is easy to use Maven, git & local deps. the main drawback I've found with deps.edn is that when I want to use a git dep, I have to fork it and add a deps.edn file, this is pretty quick and painless to do. I also find that deps files tend to be pretty simple. it's also super simple to switch between deps and lein, also you can have both at the same time in your repo and choose what to jack in with. from my experience using both for many years, deps is a lot less opinionated, and maybe that is where lein will be easier to use, until leins opinions get in your way.

lein new app hobby Now open your editor and start coding. 🙀

> when I want to use a git dep, I have to fork it and add a deps.edn file It's a good idea to open GH issue against such repos and request they add deps.edn 🙂

> lein new app hobby > Now open your editor and start coding. > 🙀 I'm confused. Is that supposed to be a huge selling point for lein? seancorfield has long since provided us 2 different scaffolding alternatives of deps-new and clj-new (which were already discussed above). You could just as easily say: > clojure -Tnew :name hobby > Now open your editor and start coding Or if you want to be a cowboy, you could go with: > echo {} > deps.edn > Now open your editor and start coding. Even that is not strictly necessary, serving mainly at that stage as a pointer to the project root for the editor tooling. You really could just open a new file, and start coding like you would a bash script.

@U90R0EPHA I think @U0PUGPSFR’s point is that to run clojure -Tnew .. you need to know about/find deps-new and follow its instructions to install it as a "tool" -- which you can't find from http://clojure.org where the official CLI docs are.

And do you not need to know about/find lein and follow its instructions to use it? Maybe I missed it, but I don't remember seeing anything about leinengen on http://clojure.org either.

You have to either follow http://clojure.org to install clojure or you have to follow Leiningen's instructions to install lein -- and many books and tutorials have the latter (but not the former).

Getting Started (on http://clojure.org) leads to Install Clojure but neither of those link to the Deps and CLI guide (so that could be improved).

(and Learn Clojure is tool-agnostic so it doesn't tell you how to start a REPL, even tho' it shows REPL sessions)

Umm, what? Installing clojure comes with installing Clojure. Then if you want scaffolding, you can either follow the brief and straightforward docs on one of your repos, or the much more complicated documentation for lein.

Actually I was hoping the deps contingent would respond with the deps equivalents so poor @U9SEPB4V9 could get on with his hobby! So Thx! 🙏

@U90R0EPHA Go read https://clojure.org/guides/install_clojure -- it does not tell you what to do after installation and it does not tell you how to start a REPL.

You have to somehow figure out that you need to click on https://clojure.org/guides/deps_and_cli to see how to start a REPL or run code with the CLI -- and that's way down on the left hand navigation.

> it does not tell you what to do after installation and it does not tell you how to start a REPL Well that seems like a very humongous oversight that should be corrected. Because starting a REPL (without lein) is literally as simple as clj in the terminal, once Clojure is installed.

(and http://clojure.org is much improved in terms of being beginner friendly than it used to be -- luckily https://github.com/clojure/clojure-site exists so folks can open issues and send PRs to improve the docs)

Wow, this turned into a wall of text. But I think it answers the original question pretty thoroughly: Possible documentation issues aside, Lein has 3 big selling points: • A long legacy of plugins built for it that can simplify many non-trivial tasks. • It serves as a 1-stop shop for everything you might want in project management, from bootstrapping a hobby project to a super-complex enterprise build system. • Most of the published books on Clojure use it (because tools.deps is fairly new and tools.build is even newer. Using tools.deps alone is not a complete solution for taking a project from empty to production, so author could not depend on it until good alternatives for building also arose). The downsides are • The legacy of its own codebase. It is monolithic and would be hard to make changes to, even if the Clojure community did not have such high expectations of API stability. • It is also monolithic in design and intent. Serving as a 1-stop shop for such varied tasks runs counter to the normally accepted values of the Clojure community. Clojurists typically prefer to build larger things from small composable pieces: at the code level, at the library level, and presumably this should also apply to tooling. In contrast to Lein, https://clojure.org/guides/deps_and_cli is minimalist, aiming to serve only and exactly the requirements of managing Clojure dependencies. It is simple in both design and usage, because it doesn't do that much. Then https://clojure.org/guides/tools_build was made to fill the void of getting a tools.deps project to production without Lein. Again, being minimalist, tools.build provides just enough power to support designing your own build pipeline, without any of the bells and whistles available with Lein. But it gets you from Clojure to an uberjar and/or gives you some basic task management for building. When you get to the stage of building, you will also likely find https://babashka.org/ to be extremely helpful. And since Babashka also has a Task feature, you could choose to sidestep tools.build altogether. This demonstrates what I mentioned earlier about Clojurists working from smaller parts. Because tools.deps and tools.build are separate you can opt use only one or the other and still have a great experience. As for plugins, tools.deps has been steadily gaining popularity. So new uncoupled tools are continually being built and published to fill in the jobs previously done by those plugins. I don't have any great insights regarding the use of Lein in books. Once you have sufficient understanding of tools.deps, you could usually just ignore the use of Lein, and do your own tooling. But that does not help a newcomer to the language. So in that case, I have to suggest using Lein (at least until you finish the book or become confident to choose otherwise). Personally I have chosen to go all in on tools.deps. I learned only as much Lein as I needed to get through educational materials, until I got comfortable with translating what I read into deps.edn file. I am extremely happy with its minimalism. But I am also the type who chooses to run Arch Linux, with a window manager instead of a desktop, and installing only exactly what I need in my operating system. So, of course, your mileage may vary.

@U064X3EF3 Fixing Clojure docs is outside of my radar for the moment, other than directing your attention when I stumble onto something. I think the discussion above highlights some pretty big weaknesses in current documentation, if you have the time and energy to address any of them.

Final thought, @U9SEPB4V9: if I start a project based on some existing framework, esp. a front-end framework, I always just go with the build set-up provided in their starter project. I just want to do app stuff, not reinvent the build stuff. hth!

@U90R0EPHA can you be more specific re docs? I think the tools.deps https://clojure.org/guides/deps_and_cli and https://clojure.org/reference/deps_and_cli and tools.build https://clojure.org/guides/tools_build cover a lot of this

Oh, I had missed a lot of this thread, I see some of what you mean

It's mostly a matter of navigation and continuity.

This is an area I’ve been working on and I have some uncommitted changes here that are coming

I think the biggest issue is a lack of direction after installing. I think install_clojure needs a link after the install instructions (duplicated for each install method) pointing to deps_and_cli and/or a link to repl/introduction, to get users started along the road of using a repl. I think for maximum continuity, my suggestion here would be a link to repl/introduction, followed up by 2 links to deps_and_cli: first one in the bottom section of the REPL Intro and second at the end of completing the REPL Guide.

agreed on the biggest gap, disagree on the some of the details but probably don't need to belabor here it here in this thread

Nothing to belabor. We agree on the important part. In your hands now. 😁

Not sure exactly what is going on, but a deftest defines a var just like a def does

So your calls to pruned by prefix are going to try and use the deftest var you are creating, not whatever pruned by prefix function you actually want to call

Are any of the other (working) tests calling pruned-by-prefix ?

@U024X3V2YN4 No. But it results in a set, so I'm not sure how I would test it without the explicit notation. Here is one of my working tests:

(deftest checking-vars
  (testing "var? functions"
    (is (= true (*var? '*foo)))
    (is (= false (*var? 'foo)))
    (is (= true (+var? '+foo)))
    (is (= false (+var? 'foo)))))

Another working test:

(deftest updating-var-val
  (testing "updated-var-val"
    (is "bar bell" (updated-var-val "bar" 'bell))))

@U0NCTKEV8 My test is called pruning-by-prefix, not pruned-by-prefix. I'm using that same symbol variation in most of my working tests.

And pruned-by-prefix is presumably defined somewhere else, and the symbol is imported by your test file?

The error message suggests that pruned-by-prefix is not interned in you testing namespace. Is there something like this in your ns declaration?

(ns my.ns-test
   (:require 
      ...
      [my.ns :refer [pruned-by-prefix]
      ...
     ))

@U024X3V2YN4 Yes, and yes.

Are you using an editor that auto-completes?

@UB3R8UYA1 I have the following (courtesy of lein new). Its working for all the other functions. I'm evaluating the source code buffer using Cider C-M-X, in Emacs.

(ns template-matcher.core-test
  (:require [clojure.test :refer :all]
            [template-matcher.core :refer :all]))

What if instead of 'all' you explicitly name pruned-by-prefix, does it flag an error?

@UB3R8UYA1 Well, the #{}-associated errors have gone away after I evaluated (C-C M-K) the whole test buffer---not just (C-M-X) the current test. Now, I also can evaluate these tests individually. Curious, but all is well. Thanks (to all)!

maybe a re-evaluation of the ns-form in your test file was what fixed it

Ah yes. That means the require clause wasn't eval'd and the symbols were never imported. :-)

Common naming convention is to add -test to the end of each test name, then it is simple to distinguish between test function and function being tested.

I just ended up writing a quick utility to make a project.clj file from the deps.edn, and then used lein checkouts as normal.