Has someone successfully deployed packages to Clojars with Boot 2.7?

i have

are you not able to?

I'm getting unauthorized response

i deployed stuff yesterday

maybe something is up with clojars today?

or can you successfully deploy with an earlier version?

2.6 works fine

whoa uh oh

Do you set the deploy url manually?

no, i just did the usual process

like the way i usually deploy things

https://github.com/boot-clj/boot/pull/540/files

possibly related?

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

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

so maybe i was using an earlier version of boot

ah ok no

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

@micha Bootlaces uses old Clojars url

ah

this is a pretty serious issue

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

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

Should fix some problems with repo credentials also

ok yeah

agree

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

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

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

does that sound right?

when deploying

I think it probably shouldn't have fallback

why not?

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

I guess that would anyway fail to missing creds

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

Hmm okay, leiningen has fallback to :repositories

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

seems like the CDN thing was maybe solved the wrong way

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

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

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

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

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

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

testing this hypothesis ^^^

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

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

@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

can you gist the output when you deploy with bootlaces?

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

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

my bootlaces is using the new url

let me try with just boot push

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

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

how do I give my creds to push?

CLOJARS_USER and CLOJARS_PASS env variables

thanks

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

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/

401 yes

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

aaah now I understand

The creds are setup against the old url: https://github.com/cljsjs/packages/blob/master/profile.boot

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

and sorry for the confusion

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

coolio

🚀

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

@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

boot-cljs-repl seems to do the same

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

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

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

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

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

we wanted that the watch task would fire, looks like

i don't remember why exactly

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

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

That is probably separate task

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

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

some look like they are for js evaluation and results

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

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

yeah, the client part now works kind of fine

of course many many things are untested

like remote clients

:asset-path and the like

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

but up to you 😉

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

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

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

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

@pesterhazy https://github.com/adzerk-oss/boot-reload/issues?q=is%3Aissue+is%3Aopen+label%3Awould-be-fixed-with-figwheel-client

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

totally

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

I see

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

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

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

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

I've been thinking about cljs repls

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

I mean I still don't understand piggieback 100%

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

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

@pesterhazy yes Dirac provides that 😁

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

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

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

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

also does it require a custom chrome devtools build?

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

hm I should give it another try

last time I checked it looked almost too ambitious

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

A tad of work 😁

I guess it is 😁😁 and very powerful

https://github.com/binaryage/dirac/blob/master/docs/installation.md looks daunting

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

@juhoteperi about on-jsload is this a valid solution? https://github.com/adzerk-oss/boot-reload/pull/105/files

Ops one sec

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

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

Right so shouldn't thep option be gone?

Yeah

I could mark the task option deprecated

perhaps later

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

at least if recompile-dependents is enabled

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

Multiple builds are not supported with autogenerated cljs.edn anyway

I guess at some point we should enforce it

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

(which runs before boot-cljs)

In any case, something to keep in mind

I will need to rebase on this I guess

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

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

And the autogenerated options require all the sources

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