@seancorfield how is the future of boot looking?

@seancorfield do you know if the authors of boot plan to continue developing boot and improving it?

@seancorfield Do you know what any of the plans are with the boot discourse website that is offline?

@nick319 Are you the same one posting this thread? https://github.com/boot-clj/boot/issues/657

I’ve never used the boot discourse, but boot seems far from abandoned to me

nick319 i'm not sure the discourse is coming back, but we do plan to continue to maintain and improve boot for the foreseeable future

Hi all: seeing some puzzling behaviour from my reloaded boot development pipeline. After starting my pipeline, the first save of my root cljs namespace triggers all of the namespaces it requires to be recompiled, even though none of them changed. Since nothing depends on the root namespace, I would have thought it would be the only one to recompile. The second time I save the root namespace, same thing happens, all the namespaces required in the root namespace are recompiled. Only the third and subsequent times, do I see the expected behaviour, which is that only root namespace is recompiled. Is this normal behaviour?

(deftask dev []
  (comp (serve)
        (watch)
        (cljs-repl)
        (reload :on-jsload 're-demo.core/init!)
        (cljs :source-map true
              :optimizations :none)
        (target :dir #{"resources"})))

{:require  [re-demo.core]
 :init-fns [re-demo.core/init!]
 :compiler-options
 {:pseudo-names   true
  :verbose        true
  :parallel-build true
  :output-dir     "js/compiled"
  :asset-path     "js/compiled"}}

just a heads up, http://boot-clj.com will be down intermittently sometimes in the next week. transferring domain, setting up SSL, cloudfront stuff at some point soon

@nick319 not sure why you tagged me in those questions? Just ask the channel in general. You got answers from at least one Boot maintainer anyway. (tagging someone often send alerts to their phone so it's kinda rude if it isn't urgent!)

@seancorfield sorry about that. I tagged you because I see you active in boot stuff. Thanks @alandipert for answering questions and taking care of boot.

@borkdude yes, I am the same person.

I am working on integrating Clojure with a software platform called Ignition, and I plan to bring people from the Ignition world over into Clojure. So I am working on making a clojure library that helps this happen as well as a new boot project template for people who want to use Clojure with Ignition, and making a new build tool plugin/task to make it easy.

So I have been evaluating using Leiningen or Boot. I really like Boot but Leiningen is older, more well known and has more tooling support in editors and such.

Last night I realized that I can't run leiningen tasks inside a normal REPL, like I can with boot -- and that I have to run every leiningen task/plugin from the command line

That made me reconsider things, because I really like using boot in the REPL, and it seems I can't do something similar with Leiningen

So then I started thinking of staying with Boot and not using Leiningen, but then wondered how stabe boot was and if it was going to continue to be maintained and improved upon, so I started asking questions. And it seems boot will continue to be a good tool and hopefully get better and better.

I am signing up with a developer membership with https://clojuriststogether.org/ and I'll be voting on boot.

@alandipert Will boot be submitting an application to https://clojuriststogether.org/ ?

@nick319 Take a look at the series of posts on my blog about our experience switching from Leiningen to Boot http://seancorfield.github.io/blog/categories/boot/

@alandipert Here is the webpage about applying for funding: https://clojuriststogether.org/open-source/

@seancorfield I am checking them out right now.

I love how easy it is to create Boot tasks as libraries. I created boot-new (since moved to Boot proper), boot-expectations (no longer needed if you use the clojure.test compatibility in Expectations), boot-kotlinc (wraps the Kotlin compiler so you can have mixed Kotlin/Clojure projects easily), and most recently boot-tools-deps (a wrapper for the new tools.deps(.alpha) library so you can define your project via deps.edn).

nick319 i don't think i will be, but i am happy to support any other contributor/maintainer who wants to

And we have a massive build.boot file at work, full of "interesting" tasks, some of which we may spin off as libraries (I'll probably package up my Marginalia task as a library next, once 0.9.2 is released at the end of the month).

@alandipert okay

@seancorfield sounds awesome. Can you tell me why "`boot-expectations` (no longer needed if you use the clojure.test compatibility in Expectations" how does that work?

@seancorfield what do you think about submitting an application to https://clojuriststogether.org/open-source/ for boot?

Expectations did not conform to the clojure.test API so it needed custom tooling (`lein-expect`, lein-autoexpect, expect-mode for Emacs, and my boot-expectations task). But I took over maintenance of Expectations and added an expectations.clojure.test namespace with functions that are compatible with clojure.test, so now all of the existing clojure.test ecosystem works with (that new style of) Expectations.

So now I use Adzerk's boot-test.

cool, great

The latest Expectations also works with Cursive's built-in test runner (based on patching clojure.test) but still needs some tweaks to better support Cursive's assumptions about test failures.

Okay, good to know. I use Cursive

@seancorfield what do you think about you submitting an application to Clojurists Together?

I have no interest in that. The Boot ecosystem seems to get along fine without needing funding etc.

ah, okay

Cider includes a feature that adds a namespace declaration at the top of a new Clojure file. It uses a function called cider-expected-ns to determine the namespace name, comparing the buffer file path to the class path. As boot caches the files in a temp directory, the classpath doesn't map directly to the source file path. Is there a way to map back to the original source file path from the cached path (other than munging the paths looking for ".boot/cache/tmp")?

I guess if there's a way to know the cache directory dynamically, that would be more portable.

There's an open ticket on this if anyone's interested: https://github.com/clojure-emacs/cider/issues/1651

actually, looking at the classpath that's returned to cider, it looks like the user-dir source files are quite heavily munged.

I just submitted an issue to the boot project about applying for funding for the project. You can see here: https://github.com/boot-clj/boot/issues/659

@alandipert @seancorfield I submitted an issue about funding: https://github.com/boot-clj/boot/issues/659

You don't need to tag us. We can see the issue.

I just released [seancorfield/boot-tools-deps "0.1.3"] which restores the correct default behavior for tools.deps(.alpha) based on the deps.edn template from the brew-install repo (so :paths is now ["src"] by default -- i.e., :resource-paths #{"src"} and the :deps and :test alias are present from that default EDN file too.

Okay, I won't tag you

fwiw i don't mind being tagged personally

so feel free, its actually helpful to me since github is like 99% noise for me

(I'm in a lot of Slacks with a lot of traffic so I try to encourage folks to tag me only when they really want my attention right there and then)

ah yeah. i'm on a few slacks myself, but only work slack is on my phone

@seancorfield how do I use them for resource paths? I think the only time to use source paths is if you're doing aot

@dominicm Not sure what you're asking...

The normal Boot convention is :resource-paths #{"src" "resources"} :source-paths #{"test"} right? That's why I've mapped :paths and :extra-paths to :resource-paths and :source-paths respectively. I think that's the answer to your question?

Looks like what I need is :fake-class-path from the boot environment

@alandipert okay, cool, good to know your stance on tagging