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
I like this, we use a “boot is the environment” thing so it’s our only hard dependency
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
what about like nodejs dependencies and so on?
like for lambda functions on aws i need a specific version of npm
yeah, thats why I want to get boot running as a native image, so I can just Lisp all the things™️
I believe there could be some synergy between the projects
Awesome! Once I start work on splitting the pods into their own library maybe you can help me test it out
yes, cool
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
I have never needed anything but the latest version
we use a few different versions, heh
# Node Build
FROM node:alpine AS node
# App Workdir
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
# Node Dependencies
COPY ./package.json /usr/src/app
RUN npm install
# Boot Build
FROM <http://cannabit.azurecr.io/cannabit-common:latest|cannabit.azurecr.io/cannabit-common:latest> AS boot
# Boot ENV
ENV BOOT_JVM_OPTIONS=-Xmx2g
# Boot Cache Dependencies
RUN boot repl -e '(System/exit 0)'
# App Workdir
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
# App Files
COPY --from=node /usr/src/app .
COPY . /usr/src/app
# App Build
RUN boot build
# Node Runtime
FROM node:alpine AS app
# App Workdir
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
# App Files
COPY --from=boot /usr/src/app/target .
CMD ["node", "nodejs"]
EXPOSE 8080
This is the build we copy-paste everywhere
so first we prep and cache as much as we can, then we download all the npm deps, then build with boot, and finally move the app to a fresh node image
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
nice!
If anyone else is interested in the experimental work on boot:
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!