I'd eventually like to use clojure and clojurescript side by side

hate to have 3-4 windows open just for that

totally

it would be a lot to do at once for me though

at first

but maybe that's just me

I think the thing that sucks

is I can get this done in leiningen with zero problems, but I really want to use boot as it appears similar to gulpjs

might just have to defer boot to clojurescript alone if I can't figure this out soon

leiningen is easier to google when you have an issue, i'm sure

yeah when i'm learning a new thing i hate getting bogged down in tooling

so do I but I keep thinking the payoff will but much higher in the long run

have you seen the modern-cljs book?

yea, was referencing it for this

that's a step by step progression

doesn't mention cider

but the benefits for clojurescript seem very real

you don't strictly need cider though

i mean eventually yes

but there is still lots of stuff to make progress on without that

and when you're more familiar with clojure and all that you can probably easily debug your cider configuration

without a good grasp of the underlying clojure stuff, it will be hard to maintain a complex tower of tooling

have a strong feeling its not my clojure config

I want C-k and C-e, just had a whole class on cl

those two things are invaluable for me

valuable*

leiningen project.clj is a static map, so you just need to learn the names of different keys etc

which stack overflow is really good at providing

I don't have a strong motivation to use boot besides the point of "it will be a better tool once I use both clojure/clojurescript"

yeah maybe you should come back to it later

boot requires that you are familiar with the underlying stuff

and cider integration is tricky

I've seen the deftasks

their not that hard

its the cider integration like you say

an alternative is inferior lisp mode

with a socket repl

something to consider

i use vim so i don't know how to do things in emacs very well

i can say that vim fireplace works without any configuration

after making a new project

for some reason it wants to work now

lol

inscrutible

thanks for the help anyways

have fun!

🙂

@micha: it does cause a problem; windows doesn't recognize "/C:/file.txt" as being a valid path, it'd need to be "C:\file.txt", altho most of the win32 API will also accept "C:/file.txt"

(map #(.getPath (URL. %))) returns the path component of a URL, I believe this would be more robust: (map #(.getPath (.toFile (Paths/get (.toURI (URL. %))))))

if I'm not mistaken, this would convert the URL to a filesystem path in a platform-independent way

seems legit to me

I think that logic would need to be applied to more than one place tho

a couple keys under (core/get-env) also contains values where there's a leading forward slash before paths

obviously doesn't cause issues internally, but as soon as a value is made available to the other windows programs, issues arise

clojure's stdlib could really use a url->path function that works everywhere

this whole thing is a minefield of issues

because some tasks want to make correlation between paths on the filesystem and URLs for like HTTP for example

things like that

indeed, minefield of issues is an understatement

then you have regexes that might match paths

there is no escape character that represents the path separator

on the other hand, everything that trickles down to a value being made available through a System property should be in the format of the current system, no?

i guess they should be in the correct format for the intended consumer

like fake.class.path system property is for editors and IDEs i think

ya

in fact the next line (partial string/join (System/getProperty "path.separator")) joins it based on the system's path separator

which is guaranteed to be : lol

fair to assume the paths should be in the system's format as well

lol, really?

yeah i think so

that's funny

I thought some systems might have ;

i think path.separator is the classpath not the PATH

actually

I get ";" as path.separator on this system

windows 7

ah interesting

so in set-fake-class-path!, I believe both boot.class.path and fake.class.path would benefit from converting the the URL to a path using Paths.get

unfortunately I only have a windows box to test it

no idea what would happen on linux or osx

i think unix machines would be fine

i think your solution looks good

i can test it anyway

'm on linux here

nice!

I wish I was on linux

working at a windows shop has its fair share of downsides

i guess using windows is one of them 🙂

is boot working okay on windows 7?

I used to have file locking issues last time I tried it, I believe, in august 2015

haven't gotten that far yet tho

i hear windows 10 solves those problems

I'm currently trying to convert one of our lein/figwheel project to boot/boot-reload, I got it to work until this issue caused vim-fireplace to not be able to display the result of a REPL eval

went through vim-fireplace for a couple hours until I realized boot was generating the wrong path format for windows in fake.class.path

debugging vimscript is tedious

haha yes

if you make a PR against master we can merge it

and i can make a 2.7.0-rc1 release

can you build boot locally?

now would be a good time for me to find out how!

I'm gonna grab dinner and look into that this evening

hopefully it's just clone repo and do make install

oh whoops

you need make

hrm

I have msys2

I dabble in rust on the weekends, lol

is anyone using :preloads with boot-cljs ? any pointers on where should I use that option? in the task or in the .edn?

phew, I did it

Just installed boot (with brew install) on machine without it, running into this problem:

any ideas?

@richhickey: 2 things: does the error still happen if you run boot -B?

2nd: what’s the output of boot -b?

does not happen with boot -B

so the problem is somewhere in your build.boot or its dependencies

(or maybe profile.boot)

it’s right there

[depsfile (io/file "deps.edn")]

but no require for

ah, I’m in a project dir with boot stuff

that was it, thanks @anmonteiro !

yeah, it’s why boot -B works, it doesn’t load the boot script

np, happy to help

-b good to know

boot -h lists all this stuff

boot -h wasn’t working either

oh, of course it wasn’t, silly me

@richhickey: do you still want to be able to use a development version of Clojure via BOOT_CLOJURE_VERSION, or do pods accomplish everything you need there?

assembling a new release, could include that

Does anyone know how to use a standalone .jar file as a dependency in build.boot?

@marc-schwartz: I have not, but just an idea; maybe :resource-paths #{"src" "lib/my.jar"}?

@timothypratley: thanks! I will try that and if not, perhaps a local mvn repo

Often recommended is installing the jar in your m2, or hosting a repo for a company

something like mvn install:install-file -Dfile=<path-to-file>

@marc-schwartz: local mvn is good, there's also boot.pod/add-classpath

@marc-schwartz: example of alan's suggestion: (boot.pod/add-classpath "lib/my.jar")

Thanks, everyone! Going with local mvn repo option...

Is it possible to have task options be recursively merged? For example, I set up some default compiler options using like this:

(task-options! cljs {:compiler-options {:language-in :ecmascript5}})

(deftask do-stuff
         []
         (comp
           ;; do stuff before
           (cljs :compiler-options {:closure-defines {'myns.core "foo"}})
           ;; do stuff after
           ))

@kenny: i believe so, check out (doc task-options!) in the repl

or here: https://github.com/boot-clj/boot/blob/master/doc/boot.core.md#task-options

Oh I see. Rather than setting the cljs task options inline I should use task-options! inside my task.

well probably not

this is what the .cljs.edn files are for

using task-options! like that isn't a good solution becuase you're mutating global state

the .cljs.edn file is scoped to the pipeline

so what you want to do is consume the existing .cljs.edn file, add options to it, then write your new version of it and add it to the fileset

using task-options! in the way you're describing will be complicated because it's not scoped to the pipeline

Ah

this is precisely the use case the .cljs.edn file is designed to accomodate

tasks that need to cooperate but don't need to know anything about each other

So then is this the preferred way to set up dev and prod build tasks: Have your .cljs.edn file(s) contain the default options for both dev and prod build tasks. If you need to set specific options for either the dev or prod task you need to read the .cljs.edn file and merge it with the options you want to set.

yeah you'd have a task that automates that

Right

Okay that makes sense for that specific case. What about in the general case where you may want to inline merge task options?

you shouldn't need to do that

the task options are only really for static things

because the task itself, the function, is global and mutable

so you don't want to be messing with that inside the pipeline

a rule of thumb is that tasks shouldn't ever mutate any global things

that's why we have the fileset

so the mutation is hidden in temp dirs, etc

if your task mutates global state in the pipline, then consider something like the watch task

one of the things that makes tasks composable is the guarantee that every time the task is called it's called with a clean environment

Righttt

if you're mutating vars you lose that

the fileset can be rewound in time, by just "commit!" an old fileset object

and pass it to the next task

task-options! is a wrapper around alter-var-root

it mutates the var

that doesn't rewind

i think maybe you want to do something like what the cljs-reload task does

when you use the reload task it looks for .cljs.edn files

it emits cljs code that it generates on the fly

then modifies .cljs.edn files such that they :require the namespaces it generated

so it can be composed with any tasks that use the .cljs.edn interface

compare that approach to for example having a :requires option for the cljs task

now the reload task would need to know about the cljs task

and it would need to mutate global state to set its options

and that isn't reversible, so the tasks that precede it in the pipeline would see the modifications it made to the cljs task

basically it's spaghetti now

everything coupled to everything

with the .cljs.edn method though, none of the tasks need to know anything about each other

they just need to know about the .cljs.edn format

in fact, you could be using a completely different cljs task

so that part works kind of like a leiningen project map

in that it's a schema for immutable data that some task will interpret

So the key here is the rewinding -- task options are not passed around like the fileset is. If they were then you would get the rewind functionality. Correct?

correct

task options though are for a different purpose

they're to pass information to the tasks about things that normally can't change over time

because the task needs to allocate long-lived resources

resources that live for the lifetime of the entire pipeline

not just one task execution

so basically for stuff that changes during the pipeline you can use the fileset to transmit info

the options are for things that the task constructor needs to know

and you can only construct a thing once

i mean once during its lifetime

Just to get some clarification.. What are you thinking I mean when I say inline merge task options?

Were you thinking this?

(deftask do-stuff
         []
         (task-options! cljs {})
         (comp
           ;; do stuff before
           (cljs :compiler-options {:closure-defines {'myns.core "foo"}})
           ;; do stuff after
           ))

ah i see, i was thinking you would be doing it in the pipline

like in the comp part

or more precisely in the handler function the task returns that becomes part of the pipline

if you do your global mutation where you have the task-options! in your example tat's better

but it does mutate that var

so if you're doing (boot (do-stuff)) in the repl you will have artifacts from the first time you do it that persist to the second time

Right. What I had originally had wanted was to do something like this:

(deftask do-stuff
         []
         (comp
           ;; do stuff before
           (cljs :compiler-options #(merge % {:closure-defines {'myns.core "foo"}}))
           ;; do stuff after
           ))

for closure defines btw i usually just use a macro

That was just for an example 🙂

js doesn't have macros so they added a special case to the compiler

Actually my specific use case is I want the {{:compiler-options {:language-in :ecmascript5}} set for all cljs tasks and I want to merge that with my :compiler-options in my task.

ok so what you want at the end of the day is to compile all your stuff as :ecmascript5?

Well, yes. But it seems like the example I posted above may be a useful functionality.

To do something like this:

(task-options! cljs {:compiler-options {:language-in :ecmascript5}})

(deftask do-stuff
         []
         (comp
           ;; do stuff before
           (cljs :compiler-options #(merge % {:verbose true}))
           ;; do stuff after
           ))

yeah that may be the best solution

In that example I want {:compiler-options {:language-in :ecmascript5}} set as default for all cljs tasks. Then in the do-stuff task I want {:compiler-options {:verbose true}} merged with the defaults for cljs.

i really try to keep things simple with the cljs compiler

and not get fancy with it

This is just an example though. It seems like it would be useful in other contexts.

the .cljs.edn way is the most powerful

the update-in way that you show above is almost as powerful

but not quite because now you need to decide which comes first in the merge

and how does that merge with the .cljs.edn file option

and so on

the .cljs.edn way you control the order in which you compose your tasks in the pipeline

so that is trivial to arrange properly

and it's not mutating anything global, so you don't need to worry about how the merge will affect things when they're applied over themselves

you can use the :id method of selecting which .cljs.edn file to operate on, like the reload and cljs-repl tasks do

so your pipeline would be like

(deftask doit
  []
  (comp
    (task1)
    (cljs-compiler-options :update #(update-in % [:closure-defines] into ['foo.bar "asdf"]))
    (taskN)
    (cljs)))

something like that

Right

Just to make sure I understand.. In the general case you are suggesting that the way you update task settings is by creating a custom file (e.g. .cljs.edn) that is understood by your task, do-stuff. If task1 or taskN wants to modify the settings for do-stuff before the do-stuff task is ran they would need to update the task specific file.

And this method is preferred because then you do not need to worry about the ordering of how certain tasks update/merge task settings

pretty much

and also when you have one task that will do different things for different artifacts

most artifacts have some sort of manifest that describes them

and you can use that manifest to build the artifact

so for jars and maven we already have a .cljs.edn thing, the pom.xml

and for war files we have the web.xml

.cljs.edn is trying to be that, but for cljs webapps

But then isn't allowing tasks to specify options inline (e.g. (task1 :some-option true)) going against that method? Because then you need to think about how your task-specific file is going to get merged with the options specified inline on the task.

yeah that's why the options should be distinct from each other

it's not like that in the cljs task because the whole .cljs.edn thing is different from what people expect

so there is overlap to make the task useful without it

it generates a default one for you if you don't make one

like the install task looks for a pom.xml in the jar file it's installing into local maven

but if you specify options to the task then those override the pom and it doesn't look for it

so it doesn't need to merge anything

but i think with the cljs task :compiler-options is an escape hatch

so things are going to be weird

the ecma5 thing maybe should be a cljs task option itself

you only run into the kinds of problems you're seeing when there is no real model for what we're doing

like arbitrary maps of things are extremely rare in boot tasks

usually we factor it out well enough so there are only a few options

the compiler options are tricky because they're coupled to each other in ways that are not easy to understand

there is a lot of work put into factoring the options to separate concerns

so we can generate the :compiler-options that work

the boot-cljs task has a whole namespace for processing that

Agreed. I believe we are on the same page now -- I just happened to pick an edge case for my leading example which caused a tangent, but very insightful, discussion. The conclusion I have drawn is that tasks will generally not have a complex map for specifying options. If the task does need a map to specify options it should be set in a task-specific file that can be overridden by task-options. If the task-specific file is overridden by task options, it should be completely overridden so you don't introduce any additional complexity of merging.

precisely!

so like in your case maybe just do your :compiler-options configs in .cljs.edn files and not in the task options

nothing in boot will enforce that, but you could just do it that way

then you'd have very fine-grained control

It seems like there could be a general task created to do this sort of thing. You specify your file and operation and the task would do the rest

yeah update nested map things

inthe fileset

Yeah

totally

a good thing to have in boot built-ins

could be something similar to the sift task maybe

All you would need to specify is :file and :fn

I guess you wouldn't be able to use it from the command line

or maybe you would have to pass in a symbol to the function or something

yeah that sounds reasonable to me

and now boot tasks can take positional parameters

so maybe like

boot doit --match-files '\.cljs\.edn$' --expr '#(update-in % [:foo :bar] conj :baz)' 

i guess it doesn't need positional parameters lol

but it could work fine from the cli too

Yeah

maybe specter has a dsl that works with the cli

i haven't used it much, but maybe there is something that matchesup with the cli there

Not sure why specter is needed here

oh probably not

What would it be replacing?

but like the way clojure.core/update-in unrolls the sexps into a sort of concatenative expression

like (-> foo (update-in [:bar] conj :baz))

i could see that working out nicely with a command line

i was thinking maybe specter has some unique possibilities for making nested data updates concatenative like that

Yeah totally. If someone want's to use it they could just require it in their build.boot and use it as they please. Not worth introducing a new dependency

oh right

although it wouldn't necessarily introduce a dependency, because it would be loaded in the worker pod

so it wouldn't be a dependency introduced to the project or anything

but yeah

overly complicated probably

I think if you get to a case where you want specter to modify your task-specific options file then you probably need to rethink your task

Clojure's default navigators should be more than sufficient. And, as you said, it is definitely the exception when a task needs complex config options.

yeah with more work we could factor all the compiler options into a cohesive whole

and then we'd have simple options to the cljs task

it's just a lot of work 🙂

Anyway, I'll be writing a task like the one discussed earlier which can certainly be used as a template/starting-place for a future built-in task.

awesome!

BTW, I was going to ask earlier but didn't want to distract from the conversation, you said you use a macro to set :closure-defines. What is the use-case for that? Right now I am just setting them using :compiler-options on the cljs task in my prod build task (obviously that isn't preferred after our discussion).

the main thing i use it for is to bring configuration settings that i make at compile time into my cljs application

i have a macro that can read the values from System/getProperty or System/getenv

Ah

also for things like logging

i have a logging macro that does a bunch of stuff but doesn't emit anything unless the log level is set in the environment or system properties when you compile

so when i compile for production i set the log level to none

and for dev to debug or whatever

Right

imo it's superior to the compiler options, because now it's in a place where you're actually computing

not as a giant case statement jammed into the gcl compiler

so i can have compile-time constants that depend on each other in different ways for instance

with all that logic encapsulated in my cljs application

not in the build settings