Fork me on GitHub
#boot
<
2015-12-20
>
escherize04:12:12

Hello, I'm new to boot. Is there a way to start a repl in a script's environment?

alandipert04:12:43

i usually boot repl in the script's directory, and then (load-file "script.boot") at the repl

alandipert04:12:11

alternatively, in the script, you can call (boot (repl))

escherize04:12:28

Thanks, I'll try those

escherize04:12:01

Nice, that was easy.

escherize04:12:56

Oh man, I've always wanted to simply add a library to a running lein repl session. I need to gush about how easy it was for myself as a boot noob to do just that! 😄!

micha04:12:07

that parrot emoji is incredible

escherize04:12:09

Yeah it's a good one. This might not be the right place for this kind of question, but: I'm trying to write a script that uses enlive to make some content pages. I went for boot since it's more of a one-off script, and simple so I can learn boot. I'm having an issue with enlive though. my 'project directory' has a directory with 2 files:

-rw-r--r--  1 escherize  staff  219 Dec 20 15:16 page.html
-rwxr-xr-x  1 escherize  staff  278 Dec 20 15:31 sausage-maker
I can slurp and spit page.html no problem. And I'm able to get deftemplate working when i set it up with lein, having the html file in my-lein-project/resources/page.html However I'm unable to get deftemplate working with the same code when page.html in any of : my-boot-project/page.html my-boot-project/resources/page.html my-boot-project/templates/page.html my-boot-project/resources/templates/page.html

micha04:12:22

@escherize: what are your :source-paths and :resource-paths?

escherize04:12:00

oh boy. probably should have a look at those. 🙉

micha04:12:16

i was asking because you have multiple files named "page.html"

micha04:12:25

can you do boot show -f please?

micha04:12:34

that will show you a tree of the files in the fileset

micha04:12:46

so you can see how your source and resource paths are interpreted and merged

escherize04:12:55

I see.

boot show -f
Implicit target dir is deprecated, please use the target task instead.
Set BOOT_EMIT_TARGET=no to disable implicit target dir.

escherize04:12:22

BOOT_EMIT_TARGET=no boot show -f
=> empty result

micha04:12:25

oh i forgot, you're not making a build script, you're making a shebang script?

escherize04:12:31

that's right

micha04:12:39

oh sorry, disregard that

micha04:12:55

in your case there's no fileset involved

escherize04:12:10

Is there something around core/add-resource that I should do

micha04:12:24

can you paste your script?

escherize04:12:55

#!/usr/bin/env boot

(set-env! :dependencies '[[enlive "1.1.6"]
                          [markdown-clj "0.9.82"]])
(require '[net.cgrand.enlive-html :as html])
(require '[markdown.core :as md])

(html/deftemplate main-template "page.html" [])

(defn -main [& args]
  (main-template))

micha04:12:43

i'm not so familiar with enlive, it's been a while since i used it

escherize04:12:51

Yeah, that's my issue too.

escherize04:12:55

it uses some weird classpath loading

micha04:12:10

what is supposed to happen?

escherize04:12:13

which works magically with lein :<

escherize04:12:25

this version would just read in page.html

micha04:12:22

ah i think i know

micha04:12:34

can you paste the output of tree . please?

escherize04:12:48

sure:

$ tree .
.
├── fake_page.html
├── page.html
├── sausage-maker
└── target

micha04:12:05

and your script is sausage-maker?

micha04:12:21

i see maybe the problem

micha04:12:32

i think lein adds src to the classpath by default

escherize04:12:41

a better tree for you is:

tree .
.
├── page.html
└── sausage-maker

escherize04:12:51

$ ./sausage-maker
    clojure.lang.ExceptionInfo: HTML resource not found.
    data: {:file "boot.user6845050520989036543.clj", :line 17}
java.lang.NullPointerException: HTML resource not found.
           net.cgrand.tagsoup/parser                       tagsoup.clj:  30
   net.cgrand.enlive-html/eval205/fn                   enlive_html.clj:  89
                                 ...
net.cgrand.enlive-html/html-resource                   enlive_html.clj:  69
net.cgrand.enlive-html/html-resource                   enlive_html.clj:  72
                        boot.user/fn  boot.user6845050520989036543.clj:  17
                                 ...
                  boot.main/-main/fn                          main.clj: 177
                     boot.main/-main                          main.clj: 177
                                 ...
                    boot.App.runBoot                          App.java: 390
                       boot.App.main                          App.java: 467
                                 ...
                    boot.Loader.main                       Loader.java: 253

micha04:12:55

so you can add the cwd to the classpath

micha04:12:02

i think that's what you want to do

escherize04:12:05

ah cool, i think so too

micha04:12:39

(set-env! :directories #(conj % "."))

micha04:12:48

if you put that before the deftemplate, does that help?

escherize04:12:08

Thanks Micha!

escherize04:12:28

where can i learn more about set-env!

escherize04:12:09

verywell. Thanks again

escherize04:12:15

time to make some sausage hah

micha04:12:26

haha ceom by if you run into any issues

alandipert05:12:39

love the parrot

micha05:12:20

cops should have that on top of their cars

micha05:12:31

i'd have to pull over, i'd be laughing too hard to get away

seancorfield05:12:29

@micha: You suggested appending "." to the Boot :directories for @escherize but would specifying :source-paths as #{"."} have worked as well?

alandipert05:12:12

@seancorfield: probably, but wouldn't have been appropriate since a fileset wasn't needed

alandipert05:12:41

we used to have an option for adding CWD as a source path, but realized people's homedirs can be pretty huge/deep... and it would lock up instantly

seancorfield05:12:25

Got it. So the fileset aspect is the decider there, thank you.

alandipert05:12:47

right, no problemo

seancorfield05:12:36

A question came up on boot-expectations (from mimmo costanza) that was essentially what's the difference between user-dirs and input-dirs, as a consideration for a task?

seancorfield05:12:23

It seemed to me that input-dirs could be a larger set, including folders that a previous task has written to?

micha05:12:31

there are two "roles" that files in a build generally have

micha05:12:35

input or output

micha05:12:41

or both, or neither

seancorfield05:12:03

So you could have a task that generated tests and you'd want input-dirs to pick up those, rather than user-dirs since the generated tests are user-supplied folders?

micha05:12:18

input are files that are potentially source files for some later task to operate on, eg. compile them, process them, etc

micha05:12:36

yes exactly as you say

micha05:12:57

output files are files that can potentially be included in the "final artifact"

seancorfield05:12:01

On the filesets page, I was surprised that assets are not considered inputs...

micha05:12:06

eg. packaged in a jar, emitted to the target dir, etc

micha05:12:31

well there are 4 permutations of #{input, output}

seancorfield05:12:37

So if you want to preprocess a file to generate CSS (for example), that file has to be a source, not an asset?

seancorfield05:12:46

(and the generated CSS file is an asset)

micha05:12:06

well the original source file must be source or resourse

micha05:12:10

*resource

micha05:12:19

because those are the ones with the "input" flag set

micha05:12:37

when you emit the css file, i would emit as "resource"

micha05:12:45

because that has both input and output flags set

micha05:12:06

so it can be input for some later task, but it will also be included in a jar or a war file

micha05:12:13

or spit into the target dir

micha05:12:36

asset paths contain files that will never be the input of any task

micha05:12:48

but will be included in the output of the pipeline

micha05:12:57

i've never found a good use for it myself

seancorfield05:12:08

The table of input/output is fairly clear -- and input-dirs follows on from that -- but the I don't think that page is all that clear on user-dirs...

micha05:12:09

but it was one of the permutations so for completeness it's there

micha05:12:49

ah, the user-dirs contain files that were created by the user

micha05:12:59

as opposed to files that were created by tasks

micha05:12:09

those could be input files or output files

seancorfield05:12:25

For web apps I can see CSS and images being assets rather than resources... but I can see the value of them also being available to later tasks.

micha05:12:31

boot needs to keep track of such things though, for various reasons

micha05:12:41

but you probably don't need to know or care about user-dirs

seancorfield05:12:04

OK, so using input-dirs in a task is normally the right thing to do?

micha05:12:04

yeah the :asset-paths are sometimes maybe helpful if you have thousands of images

micha05:12:36

yeah if you're querying over the fileset to get files i would normally use input-files or output-files

micha05:12:49

because then you can filter them, etc

micha05:12:11

usually your task is interested in a subset of all input or output files

micha05:12:24

like ones matching *.css perhaps

seancorfield05:12:11

If you output the fileset, you get series of "random" temp paths into the cache: is there an easy way to find out what real files / folders those refer to (in the user space)? Clearly Boot knows the mapping...

seancorfield05:12:23

...mostly just curiosity on my part simple_smile

micha05:12:35

like how do you mean the "real" files?

micha05:12:50

like the paths in boot's temporary directories?

micha05:12:03

or the original files you have in your project?

micha05:12:26

one thing that's a little strange is that boot doesn't operate on your files

seancorfield05:12:30

The mappings between real user folders and the temporary directories (where those exist).

micha05:12:38

it doesn't ever see the files you edit in your editor

micha05:12:46

boot copies those into temp dirs

micha05:12:02

so the fileset contains TmpFile records

micha05:12:10

those have a :file key

micha05:12:19

you can use boot.core/tmp-file to access it

micha05:12:41

that gives you a java.io.File representing the path to the actual file in the tempdir

seancorfield05:12:56

I'll try asking a different way... simple_smile

micha05:12:18

that gets the java.io.File objects for all the pom.xml files in the fileset that are input files

seancorfield05:12:13

Let's say we start with user dirs A, B, and C, and we tell Boot that A and B are resources, and C is target. Boot creates temporary directories for A, B, and C, yes? And copies (links) the original content into those temporary directories right?

micha05:12:29

ah, i see now

micha05:12:32

not exactly

micha05:12:01

the fileset has a directory for each of the types, source/resource/asset

micha05:12:24

it has one set of these for user file, and one set for non-user files

micha05:12:36

when you set :source-paths or :resource-paths etc

micha05:12:53

that attaches a filesystem event watcher to the dirs in those sets

micha05:12:14

so the dirs you specify in :resource-paths are all attached to filesystem watchers

micha05:12:31

the watchers copy files into the fileset user-dir for resource

micha05:12:37

asynchronously

seancorfield05:12:46

So... the watchers know the mapping simple_smile

micha05:12:54

yep, it's set up here:

micha05:12:03

it's a little convoluted because it's all stateful code

micha05:12:18

i guess more than a little

seancorfield05:12:18

If I get to the point where I think I have a really good handle on it, I may suggest some edits to the filesets wiki page to clarify the relationships (since reading that caused me to ask these questions).

micha05:12:35

thanks! feel free to edit at will simple_smile

tolitius07:12:08

working on making a lib boot'iful, it does not seem I can have overlapping :source-paths. I do have a set of cljc tests that use two different apps for testing: one under clj, another one under cljs:

tolitius07:12:02

(set-env! :source-paths #(conj % "test" "test/clj")) boot says: (!) :source-paths must not overlap. https://github.com/boot-clj/boot/blob/6afed5f095867870c1be9b34163aa6f4ac80a225/boot/core/src/boot/core.clj#L617

tolitius07:12:18

I can move clj and cljs apps that are used for testing outside of test, but wanted to see if I am missing something (in my first couple hours of boot)

flyboarder07:12:54

@tolitius: when you add a path everything under that path is also added

flyboarder07:12:07

including sub directories

flyboarder07:12:12

so :source-paths #{“test”} already includes test/clj and test/cljs

tolitius07:12:57

@flyboarder: yep, thanks. I do understand that, but the tests require artifacts from test apps as (require [tapp.foo.bar]), and making them do (require [clj.tapp.foo.bar]) / (require [cljs.tapp.foo.bar]) does not seem clean. converting "it" from lein. there I add both "test" and ("test/clj" or "test/cljs") depending on the platform

flyboarder07:12:32

and there are other things in test which you need i presume?

escherize08:12:26

Howdy, I'm back with my sausage-makering activities (using a boot script). Tried running it on a fresh boot install (not my machine) and getting:

clojure.lang.ExceptionInfo: Could not locate markdown/common__init.class or markdown/common.clj on classpath:
    data: {:file "markdown/core.clj", :line 1}
java.io.FileNotFoundException: Could not locate markdown/common__init.class or markdown/common.clj on classpath:
Here's the relevant part of the script:
#!/usr/bin/env boot

(set-env! :dependencies '[[enlive "1.1.6"] [markdown-clj "0.9.82"]])
(set-env! :directories #(conj % "."))
(set-env! :directories #(conj % "./content-sites"))
(require '[net.cgrand.enlive-html :as html])
(require '[markdown.core :as md])
(require '[clojure.string :as str])
(use '[])

(println (md/md-to-html-string "# Hi."))

escherize08:12:06

nevermind, I blew away ~/.boot on the offending machine and we're good to go

escherize08:12:51

thanks boot for powering our content marketing strats @ http://fetchh.io

martinklepsch13:12:44

@micha testing the above I noticed the "Implicit target dir is deprecated, ..." warning is printed even when the target task is used — is that expected?

danielsz14:12:58

@martinklepsch: Yes, you need to set the environment variable.

danielsz14:12:38

export BOOT_EMIT_TARGET=no

micha18:12:54

2.5.2 is released, boot -u to update

micha18:12:16

likewise! simple_smile

seancorfield19:12:19

@magomimmo: I'm reading your comment on boot-expectations but when I've used adzerk-oss/boot-test (on which boot-expectations is based in many ways), I didn't see the "tests all loaded namespaces" problem, as I recall: it only tested namespaces in my source code.

seancorfield19:12:00

I don't know whether that was due to my project setup or something else.

seancorfield19:12:49

Yes, I read that.

magomimmo19:12:22

@seancorfield: I used reader conditions…but I don’t think this causes the problem

seancorfield19:12:06

Sounds to me like it's related to cljs and cljc files, from reading those issues.

magomimmo19:12:16

@seancorfield: at least not for the all-ns*

magomimmo19:12:03

@seancorfield: and what about duplication?

magomimmo19:12:52

@seancorfield: I’m going to eat...

seancorfield19:12:18

I don't work with cljs and I don't use cljc (because of that) so I haven't run into any of those problems so far.

seancorfield19:12:56

I also don't experience the "all namespaces" problem shown in the Jay Fields article you linked to (which was from 2010 -- so maybe that's not even an issue any more?).

magomimmo19:12:36

`boot.user=> (doc clojure.test/run-all-tests) ------------------------- clojure.test/run-all-tests ([] [re]) Runs all tests in all namespaces; prints results. Optional argument is a regular expression; only namespaces with names matching the regular expression (with re-matches) will be tested. nil boot.user=>`

seancorfield19:12:51

Just ran boot-test against a small (pure clj) project here with several dependencies and the only namespaces it tries to test are the two that are actually in my source code. So I don't see the behavior that Jay Fields showed in his article.

seancorfield19:12:20

I know what the source code does.

seancorfield20:12:07

I'm just saying that in real world projects, I'm not seeing the behavior you claim. If you can create a small, self-contained, test repo that demonstrates a problem with boot-expectations, I'd be perfectly happy to look at the issue.

magomimmo20:12:49

so there is something that I do not understand too. what does return to you (all-ns)

seancorfield20:12:11

I don't see the problem with clojure.test in the projects we use at work (with lein test right now, but I'm not seeing it on test projects with boot test either), and I don't see the problem with boot expectations on a large project at work: I instrumented boot-expectations to print all the input namespaces it is requiring and don't see it trying to require extra namespaces and I don't see it trying to test extra namespaces.

magomimmo20:12:14

I go to see what lein test does

seancorfield20:12:00

Instead of reading the source, you could try to create a small, self-contained test projects that shows the problem...

magomimmo20:12:40

I never had the same problem with lein test too

magomimmo20:12:30

the jaycfield sample is the shorter sample. you can use it at the repl

seancorfield20:12:37

I'm not very interested in doing something at the REPL since we're talking about how boot test and boot expectations work, not how the underlying code works simple_smile

seancorfield20:12:16

Both boot test and boot expectations support include / exclude namespaces by regex (so this all seems like a moot point anyway).

micha20:12:52

hm there are PRs for boot-test i didn't see

micha20:12:00

@magomimmo: this is the PR that fixes one of the issues, right?

magomimmo20:12:44

yes, distinct should resolve the duplication issue

micha20:12:55

ok i'll push a release

magomimmo20:12:13

wow, you did in a nano second….

magomimmo20:12:25

thanks so much

micha20:12:36

you tried 1.0.7 already?

crisptrutski20:12:40

@seancorfield @misha contrary to the comment above, boot test only supports include / exclude by namespaces, unless I’ve missed something

crisptrutski20:12:06

but regex sounds darn rootin tootin’

crisptrutski20:12:45

thanks for boot expectations @seancorfield, very nice job there

micha20:12:53

there is the --filters option btw

seancorfield20:12:05

I cannot claim credit for most of boot-expectations simple_smile

micha20:12:11

you can make a predicate to determine which namespaces are included

crisptrutski20:12:29

that runs a bit later though, after loading the vars

micha20:12:43

ah, i see

seancorfield20:12:55

If distinct solves the problem with duplicates, I can add that easily to boot-expectations too. I'll open an issue to remind me for when I'm on my desktop system.

crisptrutski20:12:21

i’m still not sure if there was user error leading to those duplicates

crisptrutski20:12:27

distinct is a good safety net though

magomimmo20:12:11

@micha: give me 10 minutes….I’m eating...

crisptrutski20:12:14

@micha: here is the only commit I make to the fileset in boot-cljs-test, which I believe caused the second copy of cljs files to appear in the fileset

micha20:12:24

hm, so there are multiple files in the fileset that contain souce code for the same namespaces?

magomimmo20:12:56

@micha: yes 1.0.7 solved the duplication issue

magomimmo20:12:11

@micha: and when used alone, without cljs-test task, I do not see all the other namespaces as well

micha20:12:43

@crisptrutski: maybe the show -f task before and after cljs-test would show something?

micha20:12:30

you can use boot.core/rm to remove files from the fileset before calling commit!, or boot.core/mv if you want to move a file

micha20:12:16

that is if you're performing a transformation from say foo.cljs -> bar.cljs, and you don't want foo to be on the classpath

crisptrutski20:12:55

in my case I was actually not intending to do anything, but create a cljs file. so the duplicate clj files were totally out of leftfield

crisptrutski20:12:30

good idea with show -f, I’ll pepper that through the pipeline and see where they get added, potentially during boot-cljs

magomimmo20:12:06

boot test-cljs test still runs all namespaces (on cljs only). boot test test-cljs as well

micha20:12:17

there are also the boot.core/mv-asset, mv-resource, and mv-source functions that will maybe be something you can use

seancorfield20:12:28

So I was right that the problem you saw is related to cljs testing after all? https://clojurians.slack.com/archives/boot/p1450643591005205

crisptrutski20:12:53

@seancorfield: i think it’s a problem with doo + filesets

crisptrutski20:12:05

yeah only seeing issue with cljs also

crisptrutski20:12:39

if i recall correctly, using doo with leiningen doesn’t have the problem

magomimmo20:12:17

@seancorfield: at the moment, with the distinct form the issue is confined to test-cljs. yes it seems that you were right

micha20:12:24

maybe it's not being run in a pod?

micha20:12:57

if it's running in a pod it should be isolated, so namespaces it requires or loads won't be seen by the rest of the boot program

crisptrutski20:12:01

you need to be at least one pod down?

micha20:12:27

i mean if the problem is that doo is loading namespaces that then are confusing other tasks

micha20:12:37

it must be because doo isn't running in a pod

micha20:12:03

if you do (require 'foo) in a pod the other pods won't have foo loaded

micha20:12:26

leiningen might avoid the problem by using multiple jvms there?

crisptrutski20:12:15

nah, the issue is the other way around - when you finally run doo, which is the test runner, it runs tests for namespaces from your deps. those deps were always loaded, things like clojure.string

crisptrutski20:12:49

the doo lein plugin does boot-inspired magic - code generates an inner leiningen project

crisptrutski20:12:36

@bensu is going to see this any minute now and chastise my bad characterisation simple_smile

micha20:12:42

if you need to you could add meta to namespaces in the boot task

micha20:12:00

because the task has all the information about which namespaces need testing

micha20:12:15

so you could to alter-meta! on them to tag them

magomimmo20:12:58

there is something that interact with cljc extension

crisptrutski20:12:58

doo takes a fixed list of namespaces, like boot-test does, using that at the moment. and should support regexes itself soon. just the “default” case needs better defaults

crisptrutski20:12:22

ok, have a big file of stuff debugged, posted here: https://www.refheap.com/112956

micha20:12:26

it hasn't been easy to get all the cljs stuff working reliably

micha20:12:33

so big 👍 for that

magomimmo20:12:59

if I run boot add-source-paths -t test/cljc test it correctly run test on all the project namespaces, I mean the ones I defined my self

crisptrutski20:12:47

and here’s the source for the test suite underneath that, if you haven’t been sucked down the rabbit hole to it yet: https://github.com/crisptrutski/boot-cljs-test/tree/portable-testing/example

magomimmo20:12:17

but if I run boot add-source-paths -t test/cljc test-cljs test the test task runs any other cljc namespace, even the ones that are from a dependency

crisptrutski20:12:04

wonder if it isn’t just the output.out giving the duplicates.

magomimmo20:12:33

@crisptrutski: it’s not about duplicates anymore (thanks to distinct, it’s about causing test.cljs running the test on a lot of namespaces from the dependencies and the test on any cljc source file from the deps as well (but only that)

magomimmo20:12:25

@crisptrutski: I should try that branch….give me few minutes.

magomimmo21:12:07

@crisptrutski: with the portable branch now test behaviour is correct. it only runs the namespaces defined by me, not the ones from any portable namespace coming from a dep

crisptrutski21:12:32

try running boot test-basic in my example

crisptrutski21:12:35

that still has the issue

crisptrutski21:12:59

the other tasks are using my whacky wrap-task decorator

micha21:12:24

wrap-task is great!

magomimmo21:12:27

@crisptrutski: test-cljs still runs almost any cljs namespace (on you example and on my repo as well

crisptrutski21:12:01

you’re using the underlying tasks directly? i’m just talking about the test tasks defined in that build.boot

crisptrutski21:12:08

test-all, auto-test, etc

crisptrutski21:12:32

ok, i’ve confirmed the lein/boot split with doo

crisptrutski21:12:02

can checkout https://github.com/bensu/doo/tree/master/example and run lein doo phantom test once and boot add-tests test-cljs -e phantom respectively

crisptrutski21:12:41

sadly, that means the issue is really cljs.test/run-all-tests in CLJS itself

magomimmo21:12:49

test-all it’s ok and auto-test too. But, as you said, it’s slow

crisptrutski21:12:20

we could fix that, maybe keeping a pod around

crisptrutski21:12:42

but think this issue might be worth fixing at the root, not with a bandaid

magomimmo21:12:35

sadly, that means the issue is really cljs.test/run-all-tests in CLJS itself…it’s what I was trying to say from the beginning

micha21:12:22

perhaps a namespace blacklist could be generated from the deps? you could amortize that cost and do it asynchronously

micha21:12:38

a bandaid though

magomimmo21:12:07

to solve the (all-ns) jaycfields did this: `(defmethod report :begin-test-ns [m] (with-test-out (if (some #(:test (meta %)) (vals (ns-interns (:ns m)))) (println "\nTesting" (ns-name (:ns m))))))`

crisptrutski21:12:40

whitelist is fast enough, i think the actual perf hit was wrap-task, recreating boot-cljs-test was ending up without cljs analysis cache etc

crisptrutski21:12:51

i’m looking at how cljs-test chooses namespaces to test, comes down to a value called ::ana/namespaces in the analyzer cache.. going to see what that value looks like resp. between these lein and doo examples

crisptrutski21:12:47

ok, i take it back. they both have the problem. the lein suite just had the namespaces listed after all simple_smile

magomimmo21:12:57

wow, back from the deep water with a fish!

crisptrutski21:12:35

i’m off to sleep now, but i’ll just add include, exclude options like boot-expectations this week. it’ll be fast if they’re actual options and not bolted on with wrap-task

micha21:12:44

haha that's a good expression @magomimmo

crisptrutski21:12:16

for boot-test, as mentioned above -f could be used, but it’s a bit annoying to build the predicate

crisptrutski21:12:35

maybe boot-test wants to add some option sugar or predicate builders as sugar for this case?

crisptrutski21:12:03

not sure how you feel about just breaking semver and changing include exclude to regex

micha21:12:04

perhaps some prepackaged predicates included?

crisptrutski21:12:17

that works too

micha21:12:18

we could bump the major version, or add new options

micha21:12:29

--include-regex

crisptrutski21:12:39

breaking semver i meant a major bump - not breaking semver itself simple_smile

micha21:12:43

or actually we can do it by changing the type of the arg in boot

micha21:12:00

make the arg of type #{edn}

micha21:12:04

or something

magomimmo21:12:14

i’m going to sleep as well, good night

micha21:12:15

i guess that's not a good solution

micha21:12:27

good night!

crisptrutski21:12:47

what i like about the breaking change is that the various tasks would be somewhat standardised

micha21:12:05

and i think it would still work in most cases

crisptrutski21:12:09

because not planning on adding literal exclusions, think they’re wimpy against literal inclusions

micha21:12:26

i.e. #"foo.bar.baz" would still match the foo.bar.baz namespace

crisptrutski21:12:49

sure, as long as symbols and strings get treated as (re-pattern (str “^” ns “$”))

crisptrutski21:12:58

you could even forget hygeine simple_smile

crisptrutski21:12:33

guess that sucks for cli usage

micha21:12:33

(re-pattern (str "^\\Q" ns "\\E$")) and have hygeine too!

micha21:12:43

oh i see lol

micha21:12:45

nevermind

crisptrutski21:12:34

if you wanted backwards compat you’d need some kind of unusual signifier to actually use regexes from cli

micha21:12:40

i think we can hack it to be compatible in most cases

crisptrutski21:12:07

maybe the regexes need to be complete anyway

micha21:12:14

also we can use the ^:! meta on the option

micha21:12:18

to disable type checking

micha21:12:38

then we could accept symbols and regexes from the repl

micha21:12:46

it's probably okay to just take regexes on the command line maybe

micha21:12:56

i think in almost all cases it will work the same

crisptrutski21:12:14

yeah, as long a regexes can never be partial matches

crisptrutski21:12:36

happy to take a stab at a PR later this week

crisptrutski21:12:54

might also take a stab at your “deferred errors via fileset” idea

crisptrutski21:12:04

anyhoo - night

crisptrutski21:12:24

thanks for munching on our bugbears tonight simple_smile

micha21:12:34

i think if we bump major version we can change the cli behavior

micha21:12:45

because that's not heavily invested in by users

micha21:12:07

but we want to avoid changing the way it works for clojure

micha21:12:22

because people have invested in build.boot files and stuff that we don't want them to have to change

micha21:12:38

but breaking the cli i think is minimally annoying to users

micha21:12:15

so if we can still accomodate the old style in build.boot it would be totally acceptable i think

seancorfield22:12:24

LMK what you decide to do re: regex include / exclude — it would obviously be desirable for boot-test and boot-expectations to behave much the same way 😸

seancorfield22:12:56

And at this point it doesn’t sound like adding distinct is particularly important to boot-expectations? (but it wouldn’t hurt)

micha22:12:28

i made a PR to boot-expectations in case you decide to do that

seancorfield22:12:22

Merged. 1.0.1 released.