Fork me on GitHub
#boot
<
2015-12-01
>
alandipert01:12:34

@jaen: re: boot as root, should be OK

jaen13:12:07

Out of curiosity, can boot do something like sub-tasks? So I could for example be able to write boot create migration "migration-name"?

martinklepsch13:12:08

@jaen: the migration bit will be interpreted as a separate task...

martinklepsch13:12:39

I think the way to go for this is using options: boot create —migration “mig-name”

jaen13:12:52

I see. In that case it's probably better to have it like boot migrations -create -name "migration-name" but I still sense a bit of a mess with options, compared to if you could separate that into tasks.

jaen13:12:37

But that probably could be worked around somehow, with a simple script fronting tasks and dispatching them.

jaen13:12:58

All in all it's just a random thought I had and was curious how does that fit into how you call boot.

andreortiz14:12:54

is anyone familiar with boot-middleman? I’m trying to standup a project but keep running into this: An error occurred while installing mime-types-data. The suggestion is to make sure gem install mime-types-data -v '3.2015.1120’ installs before bundling… it installs just fine. Any ideas?

jaen14:12:58

Does it say what the error is?

jaen14:12:40

PS when you do gem install mime-types-data -v '3.2015.1120'` you're installing the gem with your system Ruby, not the jRuby used by boot-middleman, so that won't help.

andreortiz14:12:33

ah - right! So I have to install the gem via jruby

jaen14:12:47

But I don't know how to do that unfortunately

jaen14:12:19

I suppose you could install jRuby on your system

jaen14:12:48

And install the gem into YOUR_PROJECT_ROOT/.gems but I haven't tried that before so I can't know if it'll work

jaen14:12:01

But is the error anything specific?

jaen14:12:40

Because I know of two issues with boot-middleman

jaen14:12:21

First is that sometimes I get the same error for ffi gem (on first gem installation), but running boot once again fixes that.

jaen14:12:54

Another is that some Java libraries can conflict with libraries jRuby needs, this happened for example when I was using buddy and boot-middleman in one project.

jaen14:12:27

This happens because for some reason boot middleman injects all the project dependencies into the jRuby pod it runs middleman in.

jaen14:12:35

This has a fairly easy workaround

andreortiz14:12:55

the errors seem to be caused by missing gems - I’m setting up jruby and all my gems now. We’ll see how this goes...

jaen14:12:41

Basically you have to change this - https://github.com/jgdavey/boot-middleman/blob/master/src/com/joshuadavey/boot_middleman.clj#L21-l23 - to this:

(defn- make-pod []
  (pod/make-pod
   (-> (boot/get-env)
                    (assoc :dependencies [['clj.rb clj-rb-version]]))))

jaen14:12:04

@andreortiz: and running boot again didn't help?

andreortiz14:12:15

didn’t help

jaen14:12:49

Yeah, so I suppose setting up the same version of jRuby boot-middleman and installing into ./.gems might work as a workaround. Do tell whether that helps or not.

andreortiz14:12:54

I’m still poking around. boot middleman did create a .gems dir but I see a different set of gems in there than when I run gem list (jruby has been installed via rbenv).

andreortiz14:12:34

so it’s a gem management issue I’m dealing with… at least it feels that way 😉

martinklepsch14:12:59

@andreortiz: if this issue occurs with the most basic boot-middleman setup I’d suggest opening an issue

jaen14:12:01

@andreortiz: you're using --path to specify that, yes?

andreortiz14:12:35

I’m not using --path.

jaen14:12:27

I'd try using --path to install to this .gems directory.

andreortiz14:12:38

@martinklepsch: I may but the issues are on my side of the computer right now

jaen14:12:47

from inside your assets folder.

jaen15:12:14

so something like cd assets && RBENV_VERSION=that-jruby-version bundle install --path ../.gems

jaen15:12:24

But this is weird, I've never had to do things like that

martinklepsch15:12:06

I’m not sure if installing via gem is what you’re supposed to do.

jaen15:12:43

No, you're not. But it might at least let him see what's going wrong, I suppose.

jaen15:12:58

jRuby version used by boot-middleman is 1.7.16.1 BTW

andreortiz15:12:27

bundle install —path ../.gems kicked off as expected. However, boot middleman still produces the same error regarding gem install mime-types-data -v '3.2015.1120’ - I’ll have to switch versions. Currently using jruby-9.0.3.0

jaen15:12:00

Hmm, interesting

jgdavey15:12:51

@andreortiz: boot-middleman only works with jRuby 1.7.x currently

jgdavey15:12:42

I looked into updating to 9.x.x.x, but the change ended up being non-trivial due to some other deps (clj.rb). Is jRuby a project dependency?

andreortiz15:12:28

currently using 1.7.x - it doesn’t look like 1.7x has been included in the project

jaen15:12:14

@jgdavey: since you're here, what's the reasoning behind including project dependencies in the jRuby pod? I mean this conj here:

(defn- make-pod []
  (pod/make-pod (-> (boot/get-env)
                    (update-in [:dependencies] conj ['clj.rb clj-rb-version]))))

jgdavey15:12:58

No reasoning behind it at all. simple_smile I’d be happy to change to assoc

jaen15:12:00

@andreortiz: IIRC you don't need to include jRuby in dependencies by hand, boot-middleman has it as a transitive dependency.

jaen15:12:26

@jgdavey: would be nice if you could, I could then stop using my custom file to override that.

jaen15:12:49

I've had clashes between jRuby's openssl and bouncycastle from buddy because of that.

jgdavey15:12:45

@andreortiz: in you Gemfile, it looks like you may need to specifically lock the mime-types gem to 2.6.2.

jgdavey16:12:34

@jaen [com.joshuadavey/boot-middleman "0.0.6"]

jaen16:12:32

@jgdavey: whee, thanks!

eploko16:12:51

Hm, guys. I’ve got the following edn in my server-side.cljs.edn:

{:require  [myapp.core]
 :init-fns [myapp.core/main]
 :optimizations :none
 :compiler-options {:target :nodejs
                    :pretty-print true}}
It compiles fine with boot-cljs and there’s the server-side.js file and the corresponding server-side.out folder inside the target folder. The issue I’ve got is when I try to run this with node, it bails out with: > Error: Cannot find module ‘~/projects/myapp/server-side.out/goog/bootstrap/nodejs.js’ It looks like it skips the target folder while trying to locate the module. The resulting server-side.js file has this inside: > require(path.join(path.resolve("."),"server-side.out","goog","bootstrap","nodejs.js")); Which, as far as I understand, should be resolved properly, but… the devil is in the fact it doesn’t. I’ve tried to set :asset-path “target” in the cljs compiler options, but it has no effect, the resulting compiled js is the same. Any ideas on how this could be resolved?

juhoteperi16:12:42

asset-path is not used for Node target, if I recall correctly

juhoteperi16:12:33

You could try running node in the target directory

eploko16:12:16

@juhoteperi: thx for the heads up. will check if i can do that as it’s been ran by a third-party lib.

andreortiz16:12:29

@jgdavey: I’m also using RBENV - Should I specify jruby-1.7.16.1 in my .ruby-version file?

jgdavey16:12:59

rbenv and other environment managers are going to be ignored. The worker pod that is spun up has the dependency on jruby.

jgdavey16:12:15

So, you could have a .ruby-version file with whatever. I sometimes do that so that the designers I work with can use middleman directly without the JVM