Fork me on GitHub
#boot
<
2017-01-08
>
vinnyataide04:01:51

how can I debug my build.boot file?

vinnyataide04:01:23

I can't even run boot help

martinklepsch04:01:36

-B disables loading of build.boot in current dir @vinnyataide

martinklepsch04:01:29

Then there is also -b which prints the generated build script, but not sure if you need that, if you can provide a specific error that makes it easier to help you 🙂

vinnyataide04:01:56

-B is good thanks

vinnyataide04:01:25

it's exactly what I was looking for, there was a task call inside that was wrong, so disabling it I could eval each line

vinnyataide05:01:45

the error message is:

ClassNotFoundException reloaded.repl  java.net.URLClassLoader.findClass (URLClassLoader.java:381)

martinklepsch05:01:54

@juhoteperi @richiardiandrea Hey 🙂 Do you have an opinion on removing the autogeneration of main.cljs.edn? I want to disable it somehow and while that can be implemented in a backwards compatible way I wonder if we shouldn’t just remove it all together and print a warning for people who relied on it

richiardiandrea05:01:12

I am for removing it, but I guess many code bases rely on auto generating, @flyboarder was proposing a task, which could be enabled by default with the option of turning it off (therefore not generating)

richiardiandrea05:01:11

Actually we could add an option for disabling that part, what would be the use case you have in mind?

martinklepsch06:01:56

I generate cljs-edn files in the task pipeline and sometimes there a no files to generate in which case the compiler still ends up compiling “main"

pesterhazy09:01:19

@martinklepsch, how about: - cljs --edn compiles all edn - cljs --auto auto-generated main.edn - cljs warns that calling the task without an explicit flag is deprecated but continues the current behavior ?

martinklepsch10:01:53

Yeah that sounds like an option

martinklepsch10:01:20

I was also thinking maybe we split the two tasks into cljs with automatic edn and cljs* without automatic edn

martinklepsch10:01:27

Then we add a deprecation warning

martinklepsch10:01:37

and at some point we just rename the cljs* one back to cljs

micha15:01:15

@martinklepsch what about using the :ids option to indicate this behavior?

micha15:01:39

you can use (cljs :ids #{"*"} ... to indicate "compile all .cljs.edn files but only if there are some"

micha15:01:26

if you have (cljs :ids #{"foo" "bar"} ... it already works the way you want it to, right?

micha15:01:41

like it won't autogenerate main.cljs.edn?

micha15:01:08

just spitballing 😄

martinklepsch15:01:26

Yes but I can’t explicitly pass all IDs because the cljs.edn files are generated as part of the pipeline

micha15:01:40

that's what i mean

micha15:01:04

like :ids #{"*"} doesn't correspond to a real .cljs.edn file name

micha15:01:21

so it could mean "all ids"

micha15:01:37

and if that argument is present the cljs task doesn't need to autogenerate anything

micha15:01:56

it seems like there are 3 cases here

micha15:01:19

1. existing behavior where there are no ids specified and cljs autogenerates main

micha15:01:52

2. cljs.edn files are generated by user in pipeline and no ids are specified as cljs option

micha15:01:17

3. cljs.edn files are generated by user in pipeline and ids are specified as cljs option

micha15:01:45

4. edge case where cljs autogenerates main and user specifies :ids #{"main"}

micha15:01:59

so 4 cases

micha15:01:26

i think case 2 should autogenerate main, but case 3 should not

micha15:01:01

so if you don't know the ids before hand, but you know that you don't want cljs to autogenerate main, you can do :ids #{"*"}

micha15:01:46

that transforms case 2 to case 3

juhoteperi15:01:35

I'd like to see some descriptions of cases where multiple builds are used (multiple target envs?). I have never used it and to me all this seems just too complex.

micha15:01:07

i've seen people use it for doing test build + dev build

micha15:01:20

where they're testing in node or something

juhoteperi15:01:56

even separate dev and test builds sounds kind of bad solution because the code base is mostly the same and separate builds don't share compiler state

juhoteperi15:01:04

so it will do lots of unncessary work

micha15:01:21

yeah, i avoid this also

micha15:01:37

it would be good to see actual use cases

martinklepsch15:01:48

I’m toying with an idea where the separate compiler state is actually quite nice, will tell you about it later though, have to sleep now 😄

juhoteperi15:01:49

One idea I've been toying about would be to drop support for multiple builds from Cljs task and instead somehow support parallel tasks and... "modifying pipeline dynamically" (or creating it dynamically)

martinklepsch15:01:11

interceptors! 😄

martinklepsch15:01:20

That would be a nice 3.0 feature 😄

juhoteperi15:01:41

There are some cases where middleware pattern isn't perfect fit, like task cleanup hook currently

micha15:01:43

i wonder how much interest there is in a boot 3.0.0 that has lower level access but is backwards compatible with 2.x?

micha15:01:07

like we could make the pipeline architecture optional

martinklepsch15:01:27

but then you have to support both? 😛

micha15:01:30

deftask could still create pipeline meddleware factories etc

micha15:01:15

i think we could do it in a clean way, for example separating the work (the handler) from the middleware

micha15:01:29

like the handler is just a function from fileset to fileset

micha15:01:57

could be separate from the middleware, which complects control flow with the work being done

micha15:01:28

then you could possibly make more graph-like flows

micha15:01:44

like feed different tasks filetered filesets

micha15:01:52

and merge them later

micha15:01:29

that would make a lot of the multiple build setups a lot cleaner maybe

richiardiandrea17:01:15

I think it would great to collect use cases somewhere: in my experience the problem with cljs.edns is more of state sharing and it happens only if no cljs.edn is there and I need the compiler options before boot-cljs runs..I haven't had any other trouble with boot so far.

richiardiandrea17:01:50

I would like to propose a pattern for the option (nothing new, the one that lambone uses) so also maybe we can create a boot 3 wiki subsection

pesterhazy17:01:51

@juhoteperi I use multiple builds for different parts of the app (customer-facing and dashboard)

juhoteperi17:01:23

@pesterhazy That could also be done using Closure modules (though I'm not sure how easy that is currently)

richiardiandrea18:01:26

Yeah I used to use multi builds in an old project exactly because I did not know about cljs modules