Fork me on GitHub
#boot
<
2016-01-04
>
tcrawley01:01:01

I think :mirrors is the wrong way to handle clojars being down. :mirrors settings are really for using a closer repo, not as a fallback when the primary is down

tcrawley01:01:29

I've updated https://github.com/clojars/clojars-web/wiki/Mirrors to reflect replacing the existing repo with the mirror

micha01:01:30

what's the right way?

tcrawley01:01:51

it doesn't muck up the maven metadata, since the metadata stores the id of the repo

tcrawley01:01:12

so if the "clojars" id points elsewhere, the metadata will still match

tcrawley01:01:17

I'm not sure if the boot section there is the correct way - I tried merge-env! in profile.boot, but it didn't seem to work

micha01:01:31

merge-env! will merge them

micha01:01:34

you want to replace, right?

tcrawley01:01:43

yeah, so it should be a set-env!

micha01:01:44

if so then set-env! is the thing you want

tcrawley01:01:47

lemme try that

tcrawley01:01:05

do you have issues for any thing you discovered during the outage?

tcrawley01:01:11

issue numbers, that is

tcrawley01:01:34

I'm trying to put together a list of all the tooling issues that fell out of this outage

micha01:01:41

so suppose i do this and enter what is essentially a new maven repository with no real connection to the "real" clojars

micha01:01:55

and i fetch some jar, foo:bar:1.0.0

micha01:01:37

wouldn't the repo i downloaded it from (i.e., the failover clojars) now be recorded in the local maven metadata?

micha01:01:03

so if the master comes back and i don't have the failover in my :repositories anymore, i'll get a maven error

micha01:01:25

because it has a local cached artifact with the same coordinates from a different repo that's no longer in my list

tcrawley01:01:45

the _maven.repositories file would contain: bar-1.0.0.jar>clojars=

micha01:01:57

oh, it doesn't record the url

tcrawley01:01:58

since it doesn't store the actual url, just the id

tcrawley01:01:10

pretty awesome

micha01:01:13

i thought the id was arbitrary

tcrawley01:01:25

apparently it's all that matters

micha01:01:34

but apparently you need to be really careful yeah

micha01:01:41

cause it's being recorded forever in your local cache

tcrawley01:01:47

yeah, set-env! worked

tcrawley01:01:53

I'll adjust the wiki page

micha01:01:02

just, wow

tcrawley01:01:07

you know what I really liked about the _maven.repositories feature? it was added to maven in a patch release (3.0.3 I think). and it broke several of my builds

tcrawley01:01:18

that doesn't seem like a patch feature

micha01:01:02

hmm so boot calls maven central "maven-central" i think, instead of "central"

micha01:01:15

i wonder if that causes confusion betwen boot and lein

micha01:01:38

and is it something i can change now? or would that break builds

micha01:01:18

man, i always thought the id was just a friendly name for humans

tcrawley01:01:26

so things still work

micha01:01:55

oh sweet, so i can update boot then

tcrawley01:01:04

yeah, I think changing it would be fine

micha01:01:21

boot should probably do the same thing as lein, whatever that is, in these cases

seancorfield04:01:36

So, did the :mirrors thing not actually work…?

flyboarder04:01:45

@micha: 2.6.0-SNAPSHOT is failing to find some of my project files, using 2.5.5 doesnt have this issue

seancorfield04:01:18

I just updated my profile.boot with the merge-env! stuff and :mirrors but now you’ve changed the recommendation…?

seancorfield04:01:06

And what about the BOOT_CLOJARS_MIRROR env var for getting Boot to fall back to the mirror when updating itself?

alandipert04:01:32

@seancorfield: yes recommendation has changed, use set-env! the new env vars are in 2.6.0-snapshot, i bet we release 2.6 this week

alandipert04:01:18

i think we may end up making them BOOT_CLOJARS_URL per latest guidance from tcrawley

alandipert04:01:41

or maybe both... to facilitate local/private clojars mirrors

seancorfield04:01:55

Well, we’re likely to set up a Maven/Clojars mirror for our own use so I guess we’ll be using :mirrors for that...

seancorfield04:01:49

The problem with the (updated) recommendation is that now you can’t have a single code/config that works when Clojars is up as well as down — you have to change the code/config — which seems… unpleasant.

seancorfield04:01:44

(but I suppose really the right answer is to run a local proxy anyway to avoid this sort of thing)

alandipert04:01:21

that's a good point

alandipert04:01:35

an alternative is code that checks, changing config conditionally

tcrawley04:01:14

seancorfield: mirrors aren't designed for for "the source is down, fall back to a mirror instead", they are designed to be used all the time

tcrawley04:01:34

so I'd rather have folks replace the canonical repo if clojars is down

tcrawley04:01:50

and be aware that it is down, so they know they can't deploy, etc

seancorfield04:01:50

Right, I understand that (now!). I was just surprised there wasn’t a better fallback mechanism.

tcrawley04:01:03

from tooling, or from clojars?

tcrawley04:01:45

my longer term plan is to provide the repo at http://repo.clojars.org, behind a cdn, on s3 or some other blockstore

tcrawley04:01:02

which should be much more robust than the current setup

alandipert04:01:07

@tcrawley: is there a canonical place to go to see if it's up or down? like a status page of some kind

seancorfield04:01:26

So, while I have you… a question about setting up a local mirror… we’re using Archiva right now and I notice that it has a proxy for central so I assume we can use it as a local mirror?

tcrawley04:01:42

http://status.clojars.org, but that doesn't work if the DNS is borked

seancorfield04:01:48

I can add clojars as a repo for it to proxy too…

tcrawley04:01:11

it points to a pingdom page, so that page probably has it's own address

tcrawley04:01:16

I need to publish that somewhere

seancorfield04:01:32

But Archiva’s documentation is pretty awful so I’m not too sure of some of the settings for polices (Return error when / Cache failures / etc)

alandipert04:01:35

@seancorfield: in nexus the lingo is "caching proxy"

tcrawley04:01:46

you should be able to use archiva as a mirror, yes. I've never done it though

seancorfield04:01:58

I guess it would be fun to try simple_smile

tcrawley04:01:03

that's the spirit!

alandipert04:01:39

;; Problematic and ill-advised
(when-not (re-find #"is up" (slurp ""))
  (boot.util/info "Clojars looks down, using mirrors.\n")
  (set-env!
   :repositories
   [["central" {:url "" :snapshots false}]
    ["clojars" {:url ""}]]))

tcrawley04:01:00

that's one approach

micha04:01:20

i mean it's not like this is something you have to deal with on a daily basis

micha04:01:39

i'm not sure you really need to automate too much there

tcrawley04:01:51

I should do the same for the mirror itself - it only opens port 443 when http://clojars.org is down :)

tcrawley04:01:00

I can probably set up a hook from pingdom

seancorfield05:01:41

Hmm, I must be doing something wrong. Setting our Archiva repo URL as a mirror in build.boot doesn’t seem to be enough to trigger Archiva to fetch the requested artifact — it still comes from Central (or Clojars).

seancorfield05:01:16

I’ll have another shot at it tomorrow...

seancorfield05:01:53

OK, here's a weird thing... I set my local Archiva install as the mirror for both clojars and central and then deleted my local repo cache of org/* to watch where it downloaded stuff... it used http://clojars.org and http://maven.org for quite a while for artifacts and then switched over to using our mirror and then used our mirror for everything else.

seancorfield06:01:17

If I set the repositories directly to our local Archiva install and re-ran that experiment and it still used http://clojars.org and http://maven.org for the first few artifacts (which seemed to be Boot's own internal dependencies) and then switched over to Archiva.

seancorfield06:01:53

So why would the mirrors not use the mirror URLs until quite a long way through the initial drawdown of artifacts?

seancorfield06:01:32

Strangely I can even see it pulling down org.clojure/data.xml:0.0.8 from Maven, even tho' that is in Archiva (using mirrors -- using repositories directly, it will pull more things from Archiva instead).

seancorfield07:01:57

With all of that discussion earlier, will Boot support the MIRROR URL going forward (in addition to those other env vars)?

seancorfield07:01:47

Just considering whether it's worth adding that for our Archiva URL...

seancorfield07:01:19

Looking at the code in 2.6.0-SNAPSHOT, it seems that setting the mirror env var is worthwhile -- and independent from the "Clojars down" URL var change.

magomimmo10:01:34

@tbrooke I still have to think about what is the most fluid path… This week I’ get some time to read about all that stuff and then…let’s see...

malcolmsparks11:01:37

Just wondering if there is any way of installing boot from a zip (rather than letting it download itself). When I was doing some consulting in a bank recently, there was just no way the boot.exe could talk to the outside world (firewalls)

malcolmsparks11:01:09

This basically meant that boot was rejected in favor of gradle

micha13:01:01

@seancorfield: yes both will be supported

micha13:01:39

i think alan was totally right abot how every hardcoded url in boot needs to be overrideable by an environment variable

micha13:01:59

@malcolmsparks: i'll add an env var for the boot.jar download too

micha13:01:20

which should solve your problem, as you can download the jar manually and point boot to it

malcolmsparks14:01:31

@micha that would do nicely. Many of these setups have IE that is allowed (via proxies) to access the internet whereas the command shell cannot

micha14:01:14

@malcolmsparks: what do you do for maven? do they run a local proxy for that?

malcolmsparks14:01:13

@micha yes, maven and lein both have ways of routing via proxies

micha14:01:25

@malcolmsparks: boot uses the same proxy conventions as lein so you should be good there

malcolmsparks14:01:25

@micha - yes, I think that bit is fine, it's just the download step which is the first obstacle to fall at

micha14:01:52

yeah i'll add an env var and update boot.sh

malcolmsparks14:01:23

for windows, what does boot.exe actually do? there's going to be some places which ban running exes from the internet

malcolmsparks14:01:33

(asking for a friend of course!)

micha14:01:40

boot.exe is a thin wrapper that downloads boot.jar and caches it in ~/.boot/, then loads boot.jar into a classloader and calls boot.App/main with the arguments you provided on the command line

micha14:01:53

it's a java class that's packaged using launch4j

malcolmsparks15:01:16

is there a manual process on windows that can be documented in case?

micha15:01:18

i wanted to avoid having shell scripts because they're difficult to maintain

malcolmsparks15:01:03

obviously the simplicity of boot.exe is a good thing but just suggesting documenting the alternative - getting clojure up and running in big orgs needs all the help it can get

micha15:01:12

so boot.jar is cached in ~/.boot/cache/bin/<version>/boot.jar

malcolmsparks15:01:35

(in that it's hard enough persuading pointy-hair management without having any further technical hoops to jump through)

micha15:01:59

maybe an MSI installer thing?

micha15:01:08

that installs a specific version of boot?

micha15:01:22

once boot.jar is cached boot.exe won't go and search for it

malcolmsparks15:01:37

I'm really talking about a wiki page with steps like: 1. here's where you download the jar 2. here's where you put it 3. here's how to run it

micha15:01:46

oh ok, sure

micha15:01:56

that's easy enough

malcolmsparks15:01:49

I'm sure someone in the windows community would be happy to create and maintain a boot script - I know what you mean about the pain of maintenance there

micha15:01:00

@malcolmsparks: is there a resource you recommend for best practices with respect to managing installs in locked down environments?

micha15:01:25

ideally we could make something that is in line with what the security department of a company already has in place

micha15:01:15

like if we need to cryptographically sign things and make an installer that works in a certain way we can probably do that

micha15:01:28

get a cert from a CA and whatnot

malcolmsparks15:01:24

@micha it's guesswork really, many places are locked down in different ways - sometimes proxies work, sometimes not. Sometimes you'd be surprised at which sites are blocked and which aren't. But in banks I think you'd find generally everyone has IE, can use it to download jars, have access to a cmd shell (where it's proxies or nothing)

malcolmsparks15:01:55

very unlikely that installers will work - most people wouldn't have (windows) admin rights to their own machines

malcolmsparks15:01:40

these sorts of things have to go through systems that handle procurement, management authorization, license compliance and software distribution - you must fill out a form for everything

malcolmsparks15:01:06

and they definitely get hear us on slack! 😉

micha15:01:55

yeah i totally understand the need to have restrictions there

micha15:01:28

another option is maybe a docker image or something like that

micha15:01:59

you can lock down a vm a lot more easily than you can a program that's running on your machine natively

micha15:01:53

if i were doing a security audit i think i'd like to see that better than jars and scripts

socksy17:01:06

I'm having difficulty running a shebang file

socksy17:01:21

it keeps telling me "No such task (./foo)"

socksy17:01:30

as an illegal argument to boot

socksy17:01:49

following various examples i find to the letter

micha17:01:59

socksy: which operating system?

socksy17:01:23

but boot version 2.5.5

micha17:01:29

yeah that should work

micha17:01:41

is boot in your path?

micha17:01:59

#!/usr/bin/env boot

micha17:01:04

that's the shebang?

socksy17:01:08

/usr/bin/env boot works

micha17:01:49

seems like that should work

micha17:01:58

the shebang is the first line of the script, right?

socksy17:01:02

can I paste the full error here, or on refheap?

micha17:01:21

whichever, and the exact script

micha17:01:27

would be helpful

socksy17:01:48

benixos% ./hello
             clojure.lang.ExceptionInfo: java.lang.IllegalArgumentException: No such task (./hello)
    data: {:file "/tmp/boot.user5887134890587450942.clj", :line 17}
java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: No such task (./hello)
     java.lang.IllegalArgumentException: No such task (./hello)
          boot.core/construct-tasks  core.clj:  754
                                ...                
                 clojure.core/apply  core.clj:  630
                  boot.core/boot/fn  core.clj:  805
clojure.core/binding-conveyor-fn/fn  core.clj: 1916
                                ...                

socksy17:01:09

#!/usr/bin/env boot
(require '[boot.cli :refer [defclifn]])

(defn -main [] (println "hello world"))

socksy17:01:00

removed the require, same difference

tcrawley17:01:17

@seancorfield: if you do get Archiva working, would you be willing to document it on the clojars wiki?

micha17:01:05

@socksy: that script works for me with 2.5.5

micha17:01:16

i think it must be something with nixos

socksy17:01:50

if you deliberately throw an exception, does it come from the same /tmp/boot.user[blahblah].clj?

socksy17:01:56

or is that a nixos thing?

micha17:01:11

the script is written to a temp file

micha17:01:26

your hello script is incorporated into the boot.user namespace

socksy17:01:35

well apparently it isn't

micha17:01:37

which is written out to that tem file and then loaded

socksy17:01:13

is there something i can put in build.boot for it to see this file?

socksy17:01:27

(build.boot is currently non-existent)

micha17:01:06

i don't think you'll see anything interesting in there

micha17:01:33

i think maybe your system passes arguments to the shebang interpreter differently

micha17:01:03

this is the place to look i think:

micha18:01:09

@socksy: can you make a dummy script interpreter that can just print the arguments it gets from the shebang?

socksy18:01:39

i'm not sure what you mean

socksy18:01:58

in the repl, i've followed what that code should be finding

socksy18:01:29

base-pat it gets as #"^#!\s*/usr/bin/env\s+\Q.boot-wrapped\E(?:\s+.*)?$"

socksy18:01:23

which presumably doesn't match with /usr/bin/env?

micha18:01:11

can you do the same and paste the output of ./hello foo bar baz please?

socksy18:01:58

/usr/bin/env: debug-interpreter: No such file or directory curious

micha18:01:14

you need to make the debug-interpreter script in your PATH

micha18:01:24

and it needs to have execute permission set

micha18:01:42

~/bin/ is in my path on my machine

micha18:01:55

so i made the script as ~/bin/debug-interpreter

seancorfield18:01:05

I didn’t have to do anything specific: it was just slow to start mirroring the files https://clojurians.slack.com/archives/boot/p1451929697008538

seancorfield18:01:35

Well, I added the clojars repo link as a "proxy connector" but that was it.

seancorfield18:01:06

Our version of Archiva is creakingly old so I’d rather document it on a new install. We’re on 1.3.6 I think which is years old.

socksy18:01:16

ok I need to go now anyway, thanks for the help micha

socksy18:01:31

(tho last minute playing around </bin/bash doesn't exist on nixos, only /bin/sh> got the script to work identically to yours)

micha18:01:19

this may be the problem, @socksy

micha18:01:20

i'm not sure how boot even works on your system at all

micha18:01:42

@socksy: boot needs bash to run on a unix system

seancorfield19:01:41

When I do boot aot show -C, I do not see the compiled class files on the classpath. What am I doing wrong?

micha20:01:51

i think -C is not what you want there

micha20:01:08

i think you want -c, --classpath

micha20:01:32

big-c is the "fake" classpath

micha20:01:43

that's there for things like editors

micha20:01:02

that want to know about source files in the user's project, which aren't actually on the classpath

seancorfield20:01:21

My use case actually needs the "fake" classpath (because this is about tooling).

seancorfield20:01:09

So I guess I need target in there to dump the compiled files somewhere that would also get them on the classpath?

micha20:01:50

the target doesn't really have anything to do with the classpath, unfortunately

micha20:01:06

what are you wanting to do?

micha20:01:14

maybe there is an easier way

seancorfield20:01:30

Well I have some code that needs to be AOT-compiled and it needs to be on the classpath (for the tooling to pick it up)

seancorfield20:01:38

This "just worked" with Leiningen...

micha20:01:29

i'd say emit everything to a target directory perhaps

micha20:01:41

and add that to the classpath of the external tools

seancorfield20:01:14

boot aot target did not write the compiled code to target/ … I’m missing something?

micha20:01:29

no, that should do it

fappy20:01:11

@crisptrutski: I've fixed my test namespace and have encountered the next onion layer: There's something not right when I say (:require [cljs.test :refer-macros [async deftest testing is]] ... It doesn't recognize symbols like 'async or 'deftest ... https://github.com/frankhenderson/boot-cljs-test-question

seancorfield20:01:09

Figured out my initial problem with aot (I didn’t have the :namespace option set and I didn’t have anything on my :resource-paths by default). Now I’m trying to figure out another issue simple_smile

seancorfield20:01:20

I have a very strange use case (that much I know), where I need to AOT-compile some code in isolation from everything else but still get it onto the classpath for the rest of my code… so I think I’m just going to bite the bullet and do it as a dependency with a locally installed JAR.

seancorfield20:01:33

I was trying to produce only that AOT code in a (target) folder and then add that to the classpath all in a single pipeline, but Boot was helping putting everything it found on the classpath into the target folder — which is not want I want 😐

micha20:01:53

did you see the sift task, @seancorfield ?

micha20:01:15

you can use that to filter the things in the fileset

micha20:01:23

only include the things you want

seancorfield20:01:51

Yeah, but I want all the other stuff on the classpath, just not dumped into the target folder simple_smile

micha20:01:47

yeah totally

micha20:01:56

there is a --to-source option for the sift task

micha20:01:02

which will do what you want

micha20:01:10

if i understand correctly

seancorfield20:01:11

Essentially I want boot a b target c d show -C and have target only operate on a and b but still have the results of c and d on the classpath…

micha20:01:48

-s, --to-source MATCH Conj MATCH onto the set of regexes of paths to move to sources.

micha20:01:40

that will move things in the fileset such that they are input files but not output files anymore

seancorfield20:01:46

This is happening because the set-env!s all run ahead of the task bodies after I lifted them out of the pass-thru stuff...

micha20:01:58

i.e. they're on the classpath but not included in jars or emitted to target etc

micha20:01:40

set-env! in the task bodies doesn't affect the fileset

micha20:01:43

which is immutable

micha20:01:52

because the fileset is created before anoy of those run

micha20:01:01

the fileset is what the pipeline processes

micha20:01:54

on the other hand, you can afect the fileset by manipulating it directly, to obtaina new fileset

micha20:01:59

this is what the sift task does

micha20:01:31

so your situation, if i understand correctly, is that you have lots of things on the classpath, and you want to emit some of them to the target dir

micha20:01:43

but when you look in the target dir, you see extra things in there that you don't want

micha20:01:58

but you do need those extra things in the boot process, so you don't want to just delete them

micha20:01:16

is that more or less the situation?

seancorfield20:01:23

Yeah, I actually just solved it by using :source-paths instead of :resource-paths for everything except the folder containing the AOT code.

micha20:01:02

ah yeah that sift thing is equivalent to that i think

micha20:01:07

but retroactive

seancorfield20:01:11

The regex for sift would need to be "everything but …" moved to sources.

seancorfield20:01:48

So I think this will work for now, until we start building JAR files again (which is mostly what I’m trying to avoid here).

micha20:01:09

yeah that's the -v

micha20:01:21

it inverts the match to make it everything-but

micha20:01:49

but yeah setting the :source-paths is definitely the right way

micha20:01:36

but just for fun, the sift task does accept a -v, --invert option that will invert the sense of the matching

seancorfield20:01:52

Good to know. I hadn’t looked at it in detail (yet).

micha20:01:02

so sift -vs ^foo would move everything but things starting with foo to source paths

seancorfield20:01:29

Does that mean you can have multiple sift .. target .. sift .. target .. elements in the pipeline with different things getting written to different target folders along the way?

seancorfield20:01:59

OK, that’ll help when we start doing more complex stuff I suspect.

micha20:01:20

i'm going to make some examples of branching a build

micha20:01:25

like what you describe there

seancorfield21:01:26

It looks like you have to be very careful about having a pipeline that invokes target multiple times… I got a concurrent execution rejected exception on my first attempt (I added the target task to one of my tasks that was run twice in a composed pipeline).

micha21:01:10

you want to have them emit to different directories, maybe?

micha21:01:15

barp $ boot aot target -d foo target -d bar target -d baz
<< loading profile >>
Compiling 1/1 foo.bar...
Writing target dir(s)...
Writing target dir(s)...
Writing target dir(s)...

micha21:01:31

oh this may be a thing with invokeStatic

seancorfield21:01:44

The problem was I had a task A that composed tasks B and C but both B and C composed tasks that ultimately ran the same target command.

seancorfield21:01:09

That’s something I’m still struggling with: task composition does not work like "depends" in Ant simple_smile

erlis22:01:16

Hi guys! I'm following the modern-cljs series and just the other day I left in the tutorial 02 and everything was working. Today when I try

boot wait serve -d target cljs target -d target
I got an error saying clojure.lang.ExceptionInfo: java.lang.IllegalArgumentException: No such task (target)

erlis22:01:48

I must be missing something really simple I can't see

erlis22:01:37

java.lang.IllegalArgumentException: No such task (target)
          boot.core/construct-tasks  core.clj:  678
                                ...                
                 clojure.core/apply  core.clj:  630
                  boot.core/boot/fn  core.clj:  712
clojure.core/binding-conveyor-fn/fn  core.clj: 1916

micha22:01:53

@erlis: can you paste output of boot -V please?

erlis22:01:24

#
#Mon Jan 04 17:34:10 EST 2016
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_CLOJURE_VERSION=1.7.0
BOOT_VERSION=2.4.2
#App version: 2.4.2

erlis22:01:42

I'm just wondering if Mimmo updated the tutorials and introduced an error

micha22:01:56

do you have a boot.properties file in the project dir?

erlis22:01:05

don't remember too many targets parameters

erlis22:01:08

yes I don

micha22:01:26

does it say BOOT_VERSION=2.4.2 in there?

micha22:01:43

if so you can change that to 2.5.5

micha22:01:51

and you'll be in business

erlis22:01:52

#
#Sun Nov 01 16:30:38 CET 2015
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_VERSION=2.4.2
BOOT_CLOJURE_VERSION=1.7.0

micha22:01:07

that's pinning the version to 2.4.2

erlis22:01:08

let me try that

micha22:01:16

but 2.5.0 introduced the target task

micha22:01:02

you can also add BOOT_EMIT_TARGET=no

micha22:01:25

or if you have that in your ~/.boot/boot.properties or as an env var you won't need to

erlis22:01:30

I see. The tutorials were updated

erlis22:01:40

and I had an old copy locally

erlis22:01:04

here he changed it from 2.4.2 to 2.5.5

erlis22:01:30

thanks for the help!!! I was about to reset and start all over. Thanks!!

micha22:01:45

sure, come back anytime simple_smile

erlis22:01:08

Thanks for using my comment on the Windows installation on your github documentation

erlis22:01:43

I'm enjoying boot

micha22:01:47

you're on windows?

micha22:01:02

which comment was that, by the way?

erlis22:01:17

the install folder

micha22:01:36

thanks for that

erlis22:01:37

was pointing to system32 but in a windows 64 bits that gets error

erlis22:01:59

I'm in windows but now I'm using a linux box

erlis22:01:08

I can test all again in windows

erlis22:01:39

I should do that. I saw the other day in the clojure mailing list a guys complaining about boot treating windows as a second class

erlis22:01:01

so far everything has been working. I'm not doing much at the time, just learning using the tutorials

erlis22:01:25

I'll use it in Windows and I'll let you know guys if I find something weird

micha22:01:44

awesome thanks

micha22:01:55

i have access to a windows machine now for testing, too

micha22:01:06

so i will be fixing bugs as they're found

fappy22:01:50

@crisptrutski: nevermind, I have it working now

sonnyto23:01:49

is set-env! suppose to set the shell environmental variable?

sonnyto23:01:13

doesnt seem to work. I have to explicitly set it in the shell before executing boot

micha23:01:15

there is no way to set shell environment variables from within the jvm

micha23:01:39

set-env! is just for configuring boot's own environment

micha23:01:56

this is where you'd configure maven repositories, dependencies, etc

magomimmo23:01:34

@erlis: sorry to be late here…and yes, latest Sunday I updated the modern-cljs series to 2.5.5. The instruction for pinning the boot release to use are in the first tutorial…and they say exactly the same thing that @micha suggested. Thanks so much Micha for your support. I’m in debt with you simple_smile

micha23:01:36

@magomimmo: my pleasure

magomimmo23:01:29

@erlis: just an added note. At the beginning of any tutorial there is a preamble text saying something like this:

magomimmo23:01:54

@erlis: git clone etc…

magomimmo23:01:38

cd /path/to/modern-cljs

magomimmo23:01:56

git checkout se-tutorial-NN

magomimmo23:01:27

this way anything should work without @micha envolvment :-))