oooo micha thats a good idea, we should include a lein->boot task by default

i think leiningen exposes a lot of that as a library

i seem to recall making something like that a long time ago

i’ll look into it, seems like it would be fairly simple to slurp it up either way

like before boot had the minimal set of tasks you need, we used it as a crutch

yeah i think there are lots of ways you can specify dependencies in leiningen

like various profiles and whatnot

i don't think there is a simple single place in the project.clj to look to find dependencies

there are dev dependencies, test dependencies, etc

ok, then the task would either need to replicate some of the lein config or utilize lein to parse the project file

that seems rather doable, the boot-shadow task works the same way, we use shadow-cljs as a library

right, i'm pretty sure i recall loading the leiningen namespaces and using those

a few other items on my radar are the dependency loading in general, i’d like to provide options for people who also use tools/deps.edn

the next version of the boot-shadow task will exclusively pull deps from the shadow-cljs.edn file

yep, the boot cp stuff should be pretty good start for tools.deps integration

tools.deps enforces "pedantic mode" or whatever they call it

yeah the nice thing with pods is that we can mix and match

like the shadow task only pulls deps into the pod it uses for compiling, it leaves all the runtime deps to npm

right on

that's perfect

man i'm having some docker troubles

do you know about docker?

i guess this isn't the docker channel 🙂

What is the process for creating a custom clean task deletes all files in a folder except for .git?

boot isn't really designed for that kind of task, it's designed to leverage immutability in builds

so managing a mutable tree of files is not really someting you probably want to use boot for

in general, boot won't alter any of your files at all

Oh, the use case is when I run build it outputs to the target/public directory and cleans it. But now I want to make the public/target a submodule to a github pages repo so cleaning is fine, I just don’t want it to delete the .git folder if possible.

boot tasks only create or modify boot-managed files in the fileset

and those are all immutable

the only place where boot intersects with your project files is when it writes to the target dir

and that is considered write-only as far as boot tasks are concerned

you don't want a task to read from the files in there

you can look at the target task, i bet it would be easy to copy and paste that with a slight modification to do what you need

Ah ok, that’s what I’ve been looking through currently but was curious if that was the best way.

you could just add a --blacklist option perhaps

to the target task

and have it just ignore files that match a regex or something like that

like while it's cleaning

there is also the -C --no-clean option

in the existing target task

you kind of want a more granular no-clean i guess

Yeah, I saw the no clean but cleaning is still a good idea. The blacklist option sounds like what I’m after.

👍 Should Be Easy ™️

lol

@micha I do know docker!

i'm mapping in /var/run/docker.sock in my container so i can run another container inception style

that works, i can docker in docker that way

but when i map volumes it looks like i can't map a volume from level1 docker into the level2 docker

i need to map the host directory

which makes sense, but it would be great if there was a way around that

hm, I know there are volume mapping issues with docker-in-docker

https://stackoverflow.com/questions/31381322/docker-in-docker-cannot-mount-volume

this isn't technically docker in docker, i'm just making /var/run/docker.sock available in the level1 container

so it can basically call out to the host docker server

i don't run a docker server in the container

ah yes, this SO question is exactly what i'm looking for

yeah it’s not technically docker-in-docker, but I think the symlink might work for you

interesting

my workaround was to just have the paths be the same in docker as on the host

haha that's an answer there already i see

yeah, I am always weary of doing stuff between host/docker, I generally opt for either in docker or out of docker

zero upvotes tho

yeah my situation is i have some automation around deployment, cloudformation, and so on

so for managing the infrastructure stuff i like having a docker container with the right versions of everythying, like npm for aws lambda functions, etc

yeah I like the solution you have tho, it makes much more sense instead of a random symlink

but i also have submodules for the various services, clojure services and whatnot

and those all have docker containers to build them

omg, so much dockerception

so i need to run the build docker container while i'm in the infrastructure container

haha yeah

but it does achieve the goal of not maintaining a "how to prepare your system to build this service" for every service and every OS

If only there was a build tool in clojure you could wire this up with 🙊

it's like just get docker and run the build container

haha one of the best reasons to use docker is because you can then write bash scripts without needing to work around OSX braindead bash and coreutils

yeah, thats why I want to get boot running as a native image, so I can just Lisp all the things™️

without the performance hit of jvm

it works but it’s highly alpha, Im going to try and get my containers moved over to the native-image and see what kind of performance issue arise

do you think graal could be used to build a program that uses for example aws sdk?

hm, I think I saw something about that, but the thing about graal is that it’s closed world, so you need everything at build time

I would imagine the aws sdk is loaded on demand

since it’s so huge

you feed it an uberjar i guess?

yeah that might work

easiest way to find out is use the graal docker image and try building your app

i have PTSD from the cljs --advanced optimizations days

i may get triggered

lol

bahahaha

if it doesnt compile then it’s not worth investigating, with boot it compiled fine and I only had to sort out dynamic loading issues

but it seems most projects get stopped at the compile step

and never get to runtime issues 😛

also graal isnt even v1 yet

so I dont plan on releasing the boot version until that happens

i am astounded that you were able to get all the crazy classloadering to work in graal

well it’s fairly simple, you delay all the dynamic stuff to the spawned jvm

then it’s business as usual

ahh i see

really we just shift all the static stuff to graal and compile that to native

so it’s really fast

but we do drop 1 level of classloader shims which is nice

that is sweet

https://github.com/adzerk-oss/boot-clj-minimal-docker-image

nice!

If anyone else is interested in the experimental work on boot:

https://github.com/boot-clj/boot-native

awesome

https://cloud.docker.com/u/adzerk/repository/docker/adzerk/boot-clj-minimal/general

@flyboarder huge kudos for taking over 🙌 Consider applying for the next ClojuristsTogether batch, I think boot would be a great candidate and there's definitely some stuff to do 🙂

@martinklepsch I have put my hat in for that! Any funding would help go along way!