Is there a "Clojure function of the day" app somewhere? I just stumbled upon bounded-count and wondering how many more less known functions are there. An app like that can help surface such functions.

There is some reason to NOT deploy production apps with clojure -Sdeps "{:deps {my.comp/my-app {:git/url "" :sha ".."}}}" -m my.comp/my-app ?

presumably you stop previous version and then run that version which involves downloading from git (if easily visible from prod) while app is down. if you create a jar the data movement happens while the previous version is still up

Well, that's avoidable by doing -Stree first.

I don't think there's any problem with it, no.

ah good catch

Kinda similar to loading a massive jar anyway, so most tools have a solution for loading your code first

I would prefer not to run dependency resolution and fetching on each node (avoid the possibility of getting different results)

But I think you can achieve a similar effect by using clojure on a ci server to resolve and fetch once, and push individual deps to servers (skip if already there) and then push a prebuilt classpath

I've even got a poc of that https://gist.github.com/hiredman/d68cafb6aa8cea563c7b77d54f522421

You get the benefits of avoiding a large single artifact and only push changes, while avoiding the pitfalls of resolving and fetching multiple times

Pack has code which can do that

It is called "skinny"

yeah,, basically that

Some of the Datomic build stuff is similar to that

(internal stuff)

I saw a talk where rich discussed ions which made me want this

skinny + rsync + wildcards in the classpath is pretty much all of it

but the example code is kind of all in one, and doesn't require you to copy everything out to the on disk layout and then rsync it

and using wildcards in the classpath precludes some useful things, like having a single directory containing all the dependencies for multiple different versions

(which you really want to make the rsync thing work)

so ideally when you deploy you are mostly pushing just a delta

yeah, I take that back, you lose all the best stuff if you just cobble it together via skinny + rsync + wildcards

So it is mandatory to have the classpath saved exactly?

yes, you need that if you just want to push deltas

e.g. you have some directory on your server /code and are running version 1, you want to be able to rsync the new stuff over /code and then switch to version 2, and then roll back to version 1 if needed

so /code is sort of like git's object directory, a pile of everything, and it is the classpath files that tell you which parts of it fit together for which versions

so I guess the classpath files would be sort of like git refs

it looks like pack's skinny writes out the version from the deps.edn, which is likely good enough (in the poc I think I sha1'ed everything so versioned by file contents)

Is there a success story channel?

@neo2551 nice idea. there are enough to warrant a channel

@hiredman outputting a classpath file or a jar with a classpath entry were ideas I had but nobody asked for yet :)

I think it is tricky to do that independent of whatever code actually does the deploy, because the way the classpath is built will depend on how things are deployed. using relative paths works until it doesn't, and you want to java -cp cat classpath` your.main` in some other working directory for some reason

and I guess all the cool kids are deploying docker images and don't care about this kind of thing

Isn't it good idea to clone GitHub repo at remote server, build jar file and deploy it? (Everything on server) (Using ssh shell script or #spire)

yes, usually that remote server is called the ci(continuous integration) server

Github itself supports this as well (actions)

the way you would usually do that is you have something like jenkins setup to monitor a git repo, when it sees changes it generates a build(often an uberjar), and then makes it available to whatever is next

the annoying thing with that is uberjars can be rather large, and convey a lot of redundant information for upgrades (most of your deps don't change at all between versions of your code)

so the idea is to always accumulate code (your code, dependencies, etc) and then a "build" is just a small text file that points into this accumulation of code to pull together all the right versions of dependencies

so a deployment can be just pushing whatever new code needs to be accumulated on a server, and a text file describing how to build a version out of all that accumulated code

In local machine while doing development we have cached versions of dependencies on class-path, which are downloaded only on initial run of application. So, we want to have similar conditions on remote server. Right?

sort of

Having dependencies co-located with the building place of application.

but I want to do all the resolution and download once for all servers to ensure they get the same thing

just like a ci server would do

another solution to the same problem (making deployments smaller and artifacts less redundant) that I have played with is using binary diffs

if I have version 1 deployed and I want to deploy version 2, I take the uberjar for version 1 and diff it with version 2, and send the diff to the servers and have them apply it

I didn't really get far enough with that to get a feel for how much redundant shipping around of dependencies it removes

The way you are saying, we'll have to sync folder of dependencies on all servers and make sure each of them is same.

yes

I don't understand idea of diff

like a patch

given A what set of changes do you need to apply to get B

When upgrading running application, While stopping version 1 and running version 2 of application, how do you manage time duration in between? Or do you simply drop requests for this duration?

that is highly app and deployment specific, but however you answer it the same answer should work for uberjars, accumulations and classpaths, or binary diffs. some answers may even help with some of the downsides of deploying right from git

https://www.youtube.com/watch?v=thpzXjmYyGk&feature=youtu.be is the video of rhickey that caused me to start thinking beyond uberjars(and similar things) for deployments

and the deps bits is maybe 40 minutes in