Fork me on GitHub
#boot
<
2017-01-01
>
juhoteperi16:01:54

Has someone successfully deployed packages to Clojars with Boot 2.7?

micha16:01:29

are you not able to?

juhoteperi16:01:31

I'm getting unauthorized response

micha16:01:46

i deployed stuff yesterday

micha16:01:54

maybe something is up with clojars today?

micha16:01:07

or can you successfully deploy with an earlier version?

juhoteperi16:01:13

2.6 works fine

micha16:01:22

whoa uh oh

juhoteperi16:01:39

Do you set the deploy url manually?

micha16:01:53

no, i just did the usual process

micha16:01:06

like the way i usually deploy things

micha16:01:24

possibly related?

juhoteperi16:01:34

I remember reading that cdn repo is read-only, but can't fine any source for this so I'm not sure if I remember incorrectly

micha16:01:10

oh actually i might have had a boot.properties file in the project i deployed

micha16:01:20

so maybe i was using an earlier version of boot

micha16:01:35

i was able to deploy this with 2.7.1 yesterday https://clojars.org/hoplon/javelin/versions/3.9.0

juhoteperi16:01:56

@micha Bootlaces uses old Clojars url

micha16:01:35

this is a pretty serious issue

juhoteperi16:01:42

@tcrawley Can you confirm if CDN repo is only for downloads and deploys need to use the old url?

juhoteperi17:01:26

We should probably anyway separate download and deploy repos like Lein does

juhoteperi17:01:45

Should fix some problems with repo credentials also

juhoteperi17:01:33

I just another day accidentally deployed my Clojars credentials to a project repo when we decided that we start to keep project.clj in the repo for Cursive users

juhoteperi17:01:04

and because of how deploy creds are read when Boot starts-up and how the project.clj task works, my deploy creds got written to project.clj

micha17:01:22

so the logic should be look in the :deploy-repositories first, then fall back to :repositories

micha17:01:28

does that sound right?

micha17:01:53

when deploying

juhoteperi17:01:13

I think it probably shouldn't have fallback

juhoteperi17:01:52

then you can't accidentally try to push to a read-only repo

juhoteperi17:01:09

I guess that would anyway fail to missing creds

micha17:01:12

sure you can, if you put that in :deploy-repositories

juhoteperi17:01:57

Hmm okay, leiningen has fallback to :repositories

juhoteperi17:01:59

Ah not exactly, :deploy-repositories is initialized with :repositories but there is no fallback

micha17:01:03

seems like the CDN thing was maybe solved the wrong way

micha17:01:25

wouldn't that be better solved using the mirrors functionality?

micha17:01:40

like if you have a second repo that is a mirror of the canonical one

micha17:01:50

which is the case with clojars now, as far as i can tell

micha17:01:05

you'd read from the mirror but write to the canonical one

micha17:01:04

having two separate repository things always seemed like a hack to me

micha17:01:46

requires all kinds of special case logic and magic to manage it

micha17:01:48

testing this hypothesis ^^^

micha17:01:34

ok so testing confirms that if we set the CDN URL in :mirrors and the canonical URL in :repositories it does do the right thing -- it will download artifacts from the CDN and deploy to the canonical one

micha17:01:13

this seems like a much more sane way to do it, or maybe i'm missing something important

tcrawley17:01:10

@juhoteperi @micha: trying to deploy (PUT) to http://repo.clojars.org (the CDN) should automatically redirect you to http://clojars.org/repo/ - I've tested that with lein and it works, but haven't tried with bootlaces

tcrawley17:01:20

can you gist the output when you deploy with bootlaces?

tcrawley18:01:33

I can deploy successfully using a modified bootlaces (that points to the CDN url):

juhoteperi18:01:46

@tcrawley Bootlaces uses old url so no problem with that, I'm using Boot push task directly

tcrawley18:01:05

my bootlaces is using the new url

tcrawley18:01:17

let me try with just boot push

tcrawley18:01:38

FYI, this didn't work until a few days ago when I modified the CDN configuration

juhoteperi18:01:59

Could also be something with the way I set creds in Cljsjs CI setup

tcrawley18:01:09

how do I give my creds to push?

juhoteperi18:01:25

CLOJARS_USER and CLOJARS_PASS env variables

juhoteperi18:01:39

or hmm... that's with bootlaces...

tcrawley18:01:42

are you getting a 401 from the deploy? if so, I think that would mean it's redirecting and the creds are failing against http://clojars.org/repo/

tcrawley18:01:05

you should get a different error from http://repo.clojars.org if it isn't redirecting properly

juhoteperi18:01:50

aaah now I understand

tcrawley18:01:33

ah, cool. After changing that, let me know if it doesn't work

tcrawley18:01:37

and sorry for the confusion

juhoteperi18:01:39

So probably no problems with Boot or Clojars, just setup problem

juhoteperi19:01:38

Huh, why don't my links to issues&PR work on CHANGES.md

juhoteperi20:01:40

@micha Do you remember why boot-reload adds tmp-dir to :source-paths instead of just adding the file to fileset? https://github.com/adzerk-oss/boot-reload/commit/ec9d461fa52fb795e404af3cda183ca29f10e4de

juhoteperi20:01:02

boot-cljs-repl seems to do the same

richiardiandrea20:01:19

@juhoteperi I was wondering the same when I looked at it

juhoteperi20:01:35

this might explain some super strange and hard to reproduce errors I've been noticing with boot-reload client cljs file not being found

richiardiandrea20:01:16

the thing is, in the pod they are all part of :directories anyways

juhoteperi20:01:33

It might be that back then Cljs compiler didn't properly read files from classpath

juhoteperi20:01:54

But with source-paths there is additional sync step, I think

micha20:01:55

we wanted that the watch task would fire, looks like

micha20:01:10

i don't remember why exactly

juhoteperi20:01:45

Only reason I can think of is that boot-cljs might have used source-paths to setup cljs compiler input

richiardiandrea20:01:41

@juhoteperi I will probably need to change boot-cljs-repl as well for figwheel right?

juhoteperi20:01:58

That is probably separate task

juhoteperi20:01:17

Boot-cljs-repl will work together with figwheelified boot-reload

richiardiandrea20:01:15

uhm, I haven't looked into that deeply but from what I have seen figwheel has a series of callbacks to be called on the server side

richiardiandrea20:01:42

some look like they are for js evaluation and results

juhoteperi20:01:53

sure, but changes to boot-reload won't break current boot-cljs-repl

juhoteperi20:01:21

at some point we'll probably want to use figwheel repl but I don't think we need that on the first version

richiardiandrea20:01:25

yeah, the client part now works kind of fine

richiardiandrea20:01:37

of course many many things are untested

richiardiandrea20:01:50

like remote clients

richiardiandrea20:01:04

:asset-path and the like

richiardiandrea20:01:30

also there are so many changes that it might be worth living it on a branch (and -figwheel-SNAPSHOT) for a while

richiardiandrea20:01:40

but up to you 😉

juhoteperi20:01:15

I'll try to finish last oldschool boot-reload version soon and then have a look at figwheel version

richiardiandrea20:01:56

I was thinking about an option to switch between the two, but I guess it is a bit overkill

juhoteperi20:01:20

Well, we could just leave boot-reload as is and create boot-figwheel

pesterhazy20:01:32

what are going to be the advantages of a figwheel-enabled boot-reload?

juhoteperi20:01:11

Re-implementing all the figwheel features would be at least one thousand lines of more code to maintain on boot-reload

richiardiandrea20:01:13

Bruce has done a wonderful job and is continuously in touch with David Nolen for the new features

pesterhazy20:01:11

yeah the split between boot-reload and figwheel wastes energy for sure

pesterhazy20:01:14

maybe going the boot-figwheel route (essentially forking boot-reload and starting a new project) would offer some advantages

pesterhazy20:01:48

for example making breaking changes to task parameters like the infamous asset-path

juhoteperi20:01:54

Yeah, now that I think about this, that seems like the best option

pesterhazy20:01:40

I've been thinking about cljs repls

pesterhazy20:01:06

for me part of why I haven't used a repl (and instead relied on boot-reload) was that it's hard to set up

pesterhazy20:01:20

I mean I still don't understand piggieback 100%

pesterhazy20:01:47

would it be possible to include a "console" in the browser window that talks back to the repl server

juhoteperi20:01:27

in case of browser repl, the browser is the "repl server"

richiardiandrea20:01:46

@pesterhazy yes Dirac provides that 😁

pesterhazy20:01:11

juho, well yes but it needs assistance from the clj environment obviously

pesterhazy20:01:33

@richiardiandrea I saw that, is anyone using that feature?

juhoteperi20:01:35

So yes, it is possible but e.g. piggieback doesn't provide that

pesterhazy20:01:04

what I mean is, is it reliable? that's what I'm looking for mainly

pesterhazy20:01:19

also does it require a custom chrome devtools build?

richiardiandrea20:01:42

Yes it is widely used and I usually add it to my boot (check powerlaces/oot-cljs-devtools) even if I usually use the repl

pesterhazy20:01:12

hm I should give it another try

pesterhazy20:01:39

last time I checked it looked almost too ambitious

richiardiandrea20:01:42

It requires Chrome Canary , with remote debugging plus r chrome plugin

richiardiandrea20:01:02

A tad of work 😁

richiardiandrea20:01:45

I guess it is 😁😁 and very powerful

richiardiandrea20:01:57

I still prefer emacs though so boot reload and boot-cljs-repl

juhoteperi20:01:49

@richiardiandrea No, cljs.edn already allows per build options so no reason to make task options more complicated

juhoteperi20:01:30

I'm now wondering if it would just be possible to read on-jsload from compiler-options map like devtools does for it's options

richiardiandrea20:01:41

Right so shouldn't thep option be gone?

juhoteperi20:01:04

I could mark the task option deprecated

juhoteperi20:01:07

perhaps later

juhoteperi20:01:31

anyway, whole on-jsload option is just a hack that shouldn't be needed

juhoteperi20:01:43

at least if recompile-dependents is enabled

richiardiandrea20:01:50

There is a problem is this: before boot-cljs executes, there might be no cljs.edn

juhoteperi20:01:21

Multiple builds are not supported with autogenerated cljs.edn anyway

richiardiandrea20:01:22

I guess at some point we should enforce it

richiardiandrea20:01:54

Yep, the figwheel bootstrap script requires on-jsload to be created so the option needs to be in boot-reload

richiardiandrea20:01:21

(which runs before boot-cljs)

richiardiandrea20:01:33

In any case, something to keep in mind

richiardiandrea20:01:18

I will need to rebase on this I guess

richiardiandrea20:01:08

And maybe add a warning when no cljs.edn can be found

juhoteperi20:01:10

Aahh right, boot-reload used to work without cljs.edn because it created the client namespace always...

juhoteperi20:01:39

And the autogenerated options require all the sources

richiardiandrea20:01:16

Yeah I do the same, but the js-onload part is tricky and Bruce uses some timeout magic in the client. I tried without it, but it did not work, I had to inject the new init from figwheel