This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-08-29
Channels
- # admin-announcements (8)
- # beginners (1)
- # boot (127)
- # cider (17)
- # cljs-dev (17)
- # clojure (69)
- # clojure-argentina (3)
- # clojure-australia (35)
- # clojure-japan (1)
- # clojurescript (66)
- # core-matrix (2)
- # cursive (33)
- # datascript (1)
- # emacs (2)
- # hoplon (17)
- # instaparse (1)
- # melbourne (1)
- # off-topic (13)
- # re-frame (7)
- # reagent (3)
So, I’m thinking about writing some sort of task that implicitly allows me to share a set of pods across tasks. I would really like environ to be operating in the same pod as tests is, but that doesn’t seem to be possible by default.
The environ task isn’t setting system properties/env vars, it’s altering a clojure variable.
@micha: https://github.com/weavejester/environ/blob/master/boot-environ/src/environ/boot.clj#L9
Truth! So, I guess my question would be what’s the best way to work around a problem like this?
Huh, okay, it seems like a super bizarre choice to have the pod-pool be a hidden object, so to speak.
So, it would be nice to be able to do things to the clojure runtime in other tasks and have that effect “persist” into other tasks.
we use a system of pr-str
and read-string
to send java strings between pods so you can do things with them
Well, I guess the same way filesets are passed through boot middleware, I would like to see pods passed?
I'm curious to use boot for making a blog, as a way to learn about boot for the first time. I think I remember reading about the existance of a.. #{project library template workflow} to do that.
sure 👐
@estsauver: environ not working in pods is confusing, I agree. It makes many tasks that use pods almost useless if your program relies on env vars. :(
Don't know if something like middleware is the answer but it's definitely worth thinking about.
@martinklepsch: env vars work fine though
environment variables come from the environment, which can be export FOO=bar
in the shell before running the program or java -DFOO=bar
, or even something like (System/setProperty "FOO" "bar")
in your build.boot or something like environ that would set properties
if environ isn't working because of pods i would say that environ is maybe being misused
Maybe environ doing an actual setproperty call is an option for boot environ. Only thing I see is that a test suite or a ring handler might rely on an env var and that it's not supplied as people expect it. Not saying that this is wrong, only confusing/not "easy"
they have a section about why environment vars are not the same as config files and variables in your program
and when i deploy to elastic beanstalk for instance or tomcat or whateevr i set environment variables in the container when i create the environment
so the application runs anywhere, and the things that depend on where it's deployed are provided by the environment as env vars
I’m trying to debug that multiple task invocation issue
@martinklepsch: can you try a test while you're in there, disabling the extra directories being passed to the cljs compiler?
ehm, not sure what you mean. I’m looking into this: https://github.com/martinklepsch/boot-cljs-multiple-builds
I asked dnolen if all the dirs should be passed to build
The issue is that on the second invocation the cljs edn file contains something like `{:require [app.out.boot.cljs.main864 app.out.boot-cljs-multiple-builds.app app.out.boot-cljs-multiple-builds.separate app.out.cljs.core boot-cljs-multiple-builds.app boot-cljs-multiple-builds.
separate]}` which is apparently caused by cljs files from previous builds being in input-files
@martinklepsch: Do you have .cljs.edn file?
Automatically generated .cljs.edn could be broken
@micha: No aswer yet, I asked just few minutes ago
@juhoteperi: no cljs.edn is generated
@martinklepsch: Automatically generated cljs.edn should probably filter out files created by cljs compiler
https://github.com/adzerk-oss/boot-cljs/blob/master/src/adzerk/boot_cljs.clj#L213 Like here
Try calling remove-previous-cljs-output on default-main
@juhoteperi: even if both .cljs.edn files are “ handwritten"
ah no...
(this is the test case: https://github.com/martinklepsch/boot-cljs-multiple-builds
Boot-cljs shouldn't include any cljs files from input-files in cljs.edn
Or boot-cljs shouldn't change .cljs.edn at all
yeah, default-main
does scan the fileset for cljs files.
Default-main shouldn't do anyhting if there are .cljs.edn files
If it is doing something, you'll see a message about writing .cljs.edn file
@juhoteperi: so the conditional must be broken there somehow
Okay so it's creating separate.cljs.edn instead of sing the provided one
How do you run that? I did try the command on readme and couldn't reproduce
Yeah, but also app.cljs.edn
what version @juhoteperi
just clean repo
@juhoteperi: you might need to update the version number in build.boot
@micha: Yeah I see that now, that should have been mentioned in changelog etc.
@martinklepsch: Yes, reproduced with -3
I only read the first line
I guess it makes sense.
@martinklepsch: https://github.com/adzerk-oss/boot-cljs/commit/a5da6b14d78c791614e818df93a7c2234d0ef7f8
Or well, I know it makes sense. I remember thinking it should work that way but as there wasn't utility fn to do that I just used by-name.
I even saw that but somehow was confused by another commit being reverted.
Anyways, thanks!
@micha: Dnolen says passing only one dir should work and will accept a patch to fix it.
And yeah, listing all the dirs causes all the files being compiled even though they wouldn't be required by anything
@juhoteperi: what would the patch do?
Fix the analysis so that cljs.test sees the new vars in files which are not inside dirs passed to build
That was the reason to list all dirs
I'm creating a ticket about this and I'll try debugging it with Cursive
Ahhah, I found out that even order of dirs in build
matters
We need pass one dir
And there is definitely a bug
Hm yeah I guess passing just a File or URL would work
But that doesn't fix the problem with stuff not being recompiled when another ns is changed
i think if you change a deftest you only change metadata on vars, not the values the vars point to
Nope, looks like it's completely broken. I can reproduce it just with (def a "foo")
and changing the value.