This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-04
Channels
- # admin-announcements (15)
- # aws (1)
- # beginners (5)
- # boot (328)
- # cider (5)
- # cljsjs (7)
- # cljsrn (12)
- # clojure (100)
- # clojure-art (3)
- # clojure-austin (1)
- # clojure-chicago (1)
- # clojure-russia (19)
- # clojurecup (2)
- # clojured (2)
- # clojurescript (34)
- # cursive (10)
- # datavis (33)
- # datomic (9)
- # devcards (21)
- # editors-rus (1)
- # events (1)
- # hoplon (42)
- # jobs (5)
- # ldnclj (38)
- # mount (39)
- # om (140)
- # re-frame (26)
- # reagent (25)
- # spacemacs (1)
- # specter (3)
- # vim (1)
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
I've updated https://github.com/clojars/clojars-web/wiki/Mirrors to reflect replacing the existing repo with the mirror
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
I'm trying to put together a list of all the tooling issues that fell out of this outage
so suppose i do this and enter what is essentially a new maven repository with no real connection to the "real" clojars
wouldn't the repo i downloaded it from (i.e., the failover clojars) now be recorded in the local maven metadata?
so if the master comes back and i don't have the failover in my :repositories anymore, i'll get a maven error
because it has a local cached artifact with the same coordinates from a different repo that's no longer in my list
boot section updated: https://github.com/clojars/clojars-web/wiki/Mirrors#boot
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
that gives you: https://gist.github.com/0b949041d9d320dfcf71
So, did the :mirrors
thing not actually work…?
@micha: 2.6.0-SNAPSHOT
is failing to find some of my project files, using 2.5.5
doesnt have this issue
I just updated my profile.boot
with the merge-env!
stuff and :mirrors
but now you’ve changed the recommendation…?
And what about the BOOT_CLOJARS_MIRROR
env var for getting Boot to fall back to the mirror when updating itself?
@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
i think we may end up making them BOOT_CLOJARS_URL
per latest guidance from tcrawley
or maybe both... to facilitate local/private clojars mirrors
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...
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.
(but I suppose really the right answer is to run a local proxy anyway to avoid this sort of thing)
that's a good point
an alternative is code that checks, changing config conditionally
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
Right, I understand that (now!). I was just surprised there wasn’t a better fallback mechanism.
Tooling.
my longer term plan is to provide the repo at http://repo.clojars.org, behind a cdn, on s3 or some other blockstore
@tcrawley: is there a canonical place to go to see if it's up or down? like a status page of some kind
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?
http://status.clojars.org, but that doesn't work if the DNS is borked
I can add clojars as a repo for it to proxy too…
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)
@seancorfield: in nexus the lingo is "caching proxy"
I guess it would be fun to try
;; 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 " "}]]))
Hahaha...
I should do the same for the mirror itself - it only opens port 443 when http://clojars.org is down :)
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).
I’ll have another shot at it tomorrow...
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.
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.
So why would the mirrors not use the mirror URLs until quite a long way through the initial drawdown of artifacts?
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).
With all of that discussion earlier, will Boot support the MIRROR URL going forward (in addition to those other env vars)?
Just considering whether it's worth adding that for our Archiva URL...
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.
@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...
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)
This basically meant that boot was rejected in favor of gradle
@seancorfield: yes both will be supported
i think alan was totally right abot how every hardcoded url in boot needs to be overrideable by an environment variable
@malcolmsparks: i'll add an env var for the boot.jar download too
which should solve your problem, as you can download the jar manually and point boot to it
@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
@malcolmsparks: what do you do for maven? do they run a local proxy for that?
@micha yes, maven and lein both have ways of routing via proxies
@malcolmsparks: boot uses the same proxy conventions as lein so you should be good there
@micha - yes, I think that bit is fine, it's just the download step which is the first obstacle to fall at
for windows, what does boot.exe actually do? there's going to be some places which ban running exes from the internet
(asking for a friend of course!)
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
is there a manual process on windows that can be documented in case?
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
(in that it's hard enough persuading pointy-hair management without having any further technical hoops to jump through)
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
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
@malcolmsparks: is there a resource you recommend for best practices with respect to managing installs in locked down environments?
ideally we could make something that is in line with what the security department of a company already has in place
like if we need to cryptographically sign things and make an installer that works in a certain way we can probably do that
@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)
very unlikely that installers will work - most people wouldn't have (windows) admin rights to their own machines
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
and they definitely get hear us on slack! 😉
you can lock down a vm a lot more easily than you can a program that's running on your machine natively
if i were doing a security audit i think i'd like to see that better than jars and scripts
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
...
#!/usr/bin/env boot
(require '[boot.cli :refer [defclifn]])
(defn -main [] (println "hello world"))
@seancorfield: if you do get Archiva working, would you be willing to document it on the clojars wiki?
if you deliberately throw an exception, does it come from the same /tmp/boot.user[blahblah].clj?
@socksy: can you make a dummy script interpreter that can just print the arguments it gets from the shebang?
I didn’t have to do anything specific: it was just slow to start mirroring the files https://clojurians.slack.com/archives/boot/p1451929697008538
Well, I added the clojars
repo link as a "proxy connector" but that was it.
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.
(tho last minute playing around </bin/bash doesn't exist on nixos, only /bin/sh> got the script to work identically to yours)
When I do boot aot show -C
, I do not see the compiled class files on the classpath. What am I doing wrong?
that want to know about source files in the user's project, which aren't actually on the classpath
My use case actually needs the "fake" classpath (because this is about tooling).
So I guess I need target in there to dump the compiled files somewhere that would also get them on the classpath?
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)
This "just worked" with Leiningen...
boot aot target
did not write the compiled code to target/
… I’m missing something?
@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
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
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.
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 😐
did you see the sift
task, @seancorfield ?
Yeah, but I want all the other stuff on the classpath, just not dumped into the target folder
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…
that will move things in the fileset such that they are input files but not output files anymore
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...
on the other hand, you can afect the fileset by manipulating it directly, to obtaina new fileset
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
but you do need those extra things in the boot process, so you don't want to just delete them
Yeah, I actually just solved it by using :source-paths
instead of :resource-paths
for everything except the folder containing the AOT code.
The regex for sift
would need to be "everything but …" moved to sources.
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).
but just for fun, the sift
task does accept a -v
, --invert
option that will invert the sense of the matching
Good to know. I hadn’t looked at it in detail (yet).
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?
OK, that’ll help when we start doing more complex stuff I suspect.
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).
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)...
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.
That’s something I’m still struggling with: task composition does not work like "depends" in Ant
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)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
#
#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
#
#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
https://github.com/magomimmo/modern-cljs/commit/bc72d37a249666fb71b4137d266904393417e3e1
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
so far everything has been working. I'm not doing much at the time, just learning using the tutorials
@crisptrutski: nevermind, I have it working now
@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
@magomimmo: my pleasure