Fork me on GitHub

`(boot (cljs :optimizations :none)) java.util.concurrent.ExecutionException: java.lang.RuntimeException: EOF while reading java.lang.RuntimeException: EOF while reading`


'''(boot (cljs :optimizations :none)) java.util.concurrent.ExecutionException: java.lang.RuntimeException: EOF while reading java.lang.RuntimeException: EOF while reading'''


Anyhow is it possible to get more info? I only get EOF with clojurescript


(boot (cljs :optimizations :none))

java.util.concurrent.ExecutionException: java.lang.RuntimeException: EOF while reading
             java.lang.RuntimeException: EOF while reading


Anyone who got a pointer on how to define development time env vars with boot?


I’m using environ to pull env vars but I’m not sure if there is a way to declare env vars in build.boot


@martinklepsch: Thanks for pointing that out. Interesting discussion on #C03S1L9DN. I think it would be great if the boot gurus joined forces with the figwheel guru so that great things could come about and really advance the state of the art here. simple_smile


> but were themselves monolithic tools that made far too many assumptions about what combination of "stuff" I wanted to use in my project. @meow: care to elaborate what those were?


@martinklepsch: Sure. For these projects I'm creating simple single-page apps using different react-based tools like om, reagent, re-frame, freactive, etc. I'm keeping the html page down to a bare minimum, and I'm using Garden to render the css, which I am inserting into the component or dom header, but not rendering to an actual .css file. I wanted to use boot and went looking for boot-based tools. The ones I found gave me more than what I wanted and I couldn't figure out an easy way to simplify them. For example, some also had server-side tooling that I didn't need. Others generated complex directory and file structures when I wanted to keep things simple. Others generated css files, when I want to keep all the css in cljs. Make sense?


Well to some extent. What was the server-side thing? (just out of curiousity)


@martinklepsch: The tools I found might be completely capable of what I wanted. But if so, I couldn't figure out how, got frustrated, so I rolled my own. I still used boot. But I didn't become a customer of the other tool, so to speak.


One thing to keep in mind with your specific problem though: if you want to generate CSS on the client then that’s probably not a build tool concern but rather an application concern.


server-side like compojure and secretary routing and db stuff


@meow: would you mind sharing your build.boot and/or the tooling you’ve built on your own?


I still need Garden to do the css


@meow: right but that’s just a regular dependency.


@martinklepsch: What's an irregular dependency? 😉


@meow: That seems like a perfectly usual build.boot file


@martinklepsch: It is. Maybe I confused you. I didn't mean to imply that anything I have is unusual. It's just that I had to roll my own and it was rather painful to do so. It just seems like folks that use figwheel and leiningen are able to find templates and so forth far more easily. Is that not the case? I'm still learning...


pkobrien: the core design goal of boot is to make it straightforward for users to make their own lightweight tasks without sacrificing composability


@meow: so the way you're using it is exactly how we hoped people would use it


@meow: you see a task that does almost what you need, that's great, you can use the underlying functions that task uses but make your own task that uses them a little differently


and since composability is preserved you don't need to rewrite all the tasks


just the ones that don't exactly work for you


@meow: the "tools" you are referring to are not tools but examples of what you can do with boot. Those are not supposed to be used as is. Leiningen offers template to help you start but in the end this is just code generation so you have to manage it yourself.


I guess when I started with boot I also looked for boot-based options that would keep me from having to learn all the details of boot and what I found were tools that weren't as flexible as I needed.


Probably there could be libraries of higher level boot tasks (like bootlaces?) but those do not exist yet. Boot is still pretty young.


pkobrien: you only need to learn "all the details of boot" in the same way that you need to learn "all the details of Clojure"


@jeluard: I guess I didn't realize that the tools I found weren't meant to be used as is.


i mean there are concepts, but at the end of the day boot is just a library you can use as part of a clojure program


your build.boot file is really just a clojure program that uses functions in namespaces


so understanding how to use those functions is necessary, as is knowing what it is you want to accomplish


@meow: what tools are you referring to?


so it's not easy, but it is simple


@micha: I understand what you are saying and now that I know boot better I really like it. At the same time, I created a lot of sample projects using Leiningen without knowing much at all about Leiningen (and still don't). Granted, they are two entirely different approaches, but I didn't really understand just how different they are.


kardan: is what you’re looking for.


pkobrien: the difference is when leiningen doesn't do what you want. then the easy vs. simple tradeoff starts to hurt


@martinklepsch: Several people active in this space have tools/examples/whatever that are based on boot. I'd rather not name them in the context of this discussion because I don't want my critique of the state of "dependency-management" and "build tooling" to appear to be directed at any one person or project. I'm just trying to provide feedback from a newbie. It seems like there is some middle ground between boot and leiningen that is worth exploring.


I think that middle ground could be built on top of boot. I don't think everyone needs to learn so much about boot to start using it. I'm still not sure I'm getting all the benefits from my own boot setup that a user of Leiningen and Figwheel are getting. Does that make any sense?


@meow: feel free to message me privately.


Leiningen made it so easy, so absolutely, positively, rewarding easy for me to start learning clojure and have immediate success with it. That's valuable.


I remember having that very similar experience and I'm still very thankful that leiningen exists.


That's the whole "well-designed-lisp in a repl" reward that we all love, right?


i think the "easy" part is just a matter of accumulating enough boot questions on stack overflow


that's what's easy about lein i think


just tons of people making things you can paste into a buffer


which is valuable, i agree


Arguably boot makes it even simpler. Doc is still rather technical maybe.


like clojure itself simple_smile


Now I've moved on and want to use boot with cljs and I want to make sure I'm not missing out on the experiences that the figwheel folks are having, but figwheel doesn't work with boot, right? I might have the same repl-reloading stuff with my boot projects. I certainly tried to get there. But I'm not sure. So if Mr. Figwheel wants to break his stuff up and make it more independent and composable and usable by both the lein and boot communities I think that would be great. Then both communities can build on it and take things even further.


@meow: we used figwheel as a reference when making the boot reload task, much of the code in there is at least based on figwheel code


@micha: Okay, cool. I thought my setup was giving me all the same features. simple_smile


haha, i think it does pretty much the same


One thing I definitely stumbled on was understanding what files need to be where, what files would end up getting generated, what to change so that the inputs and outputs were what I wanted them to be, etc. That was because some of it is based on default values, some is based on edn file names, some is typically configured in the boot file, etc. It isn't a terrible combination, and there are good reasons for it all, but as a beginner it took a while to figure out.


This is for cljs, so my index.html needs to refer to a script of a certain name in a certain location. The name and location are the .js file, which typically ends up not being the same name as the .cljs source file. Different people and different examples have different conventions for these names and locations. And the common conventions in the boot community do not match the convention used by dnolen in the cljs quick start guide. Can you understand why I might have gotten a little frustrated? 😉


The mistake I made was trying to retain the names and locations used in the cljs quick start while adding boot to the mix. That didn't work so well. So then I looked for and found examples/tools based on boot that supported cljs, om, sablono, garden, etc. Each one used a different directory structure and naming convention. Gradually I figured out where these names and locations were controlled in boot itself, got things to work the way I wanted, and that's where I am today. The next thing I want to do is have my index.html and .js files hosted on gh-pages and I am dreading having to go back into learning mode to figure out how to get boot to generate those files in a specific way that makes sense for the context of keeping them in a gh-pages branch. 😞


The ultimate insult is that all of this is super easy stuff, except for the first time you encounter it. Making that first time easier and less time-consuming for the next guy is what I'd like to see come out of my complaining here.


i guess the thing with boot is that you're writing a program


this is not like leiningen or a declarative build process, where you're filling in a form


both have their advantages and disadvantages


in the long run i'm pretty sold on non-declarative build tooling, personally


i need to be able to program everywhere


but if you are just starting out i think leiningen is probably a better choice


because you can cut and paste a lot of stuff and it will probably work


there are only so many things you want to be learning at one time


@micha: I don't think boot is the problem. I think there are just some things missing surrounding boot. Like in the example I just gave. If there was a wiki page on boot that started where the cljs quick start ends that would have saved me a ton of time and frustration.


ah, i see


yeah that's a great point


And the examples that I found that provided way more stuff than I wanted. That isn't really the fault of those examples. If you want all the server side tools and the client-side tools then those examples are great. There just need to be more intermediate examples, perhaps.


i should be more active on stack overflow perhaps


i think examples like what you describe can really benefit from the upvote/downvote mechanism


And maybe some FAQ stuff, like, if you have an index.html file and need to refer to a .js script then you control the name of that script via the .cljs.edn file name and its location is determined by this env option which you can change in this file at this location, etc, etc.


And if you don't provide these options in your boot file then the following defaults will take effect.


Baby steps...


And something on "How to use boot to host your cljs application on gh-pages" would be awesome. 😉


if you write a blog post about it we can link to it simple_smile


@micha: nice try... rofl simple_smile


have a good one!