This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-02
Channels
- # announcements (11)
- # aws (2)
- # babashka (42)
- # beginners (26)
- # calva (17)
- # cider (1)
- # clara (2)
- # clj-kondo (44)
- # clojars (30)
- # clojure (43)
- # clojure-australia (6)
- # clojure-europe (29)
- # clojure-gamedev (4)
- # clojure-greece (1)
- # clojure-nl (4)
- # clojure-spec (4)
- # clojure-uk (6)
- # clojurescript (28)
- # cursive (16)
- # data-science (1)
- # datahike (4)
- # datomic (26)
- # emacs (6)
- # events (3)
- # fulcro (11)
- # graalvm (7)
- # holy-lambda (118)
- # java (9)
- # jobs (1)
- # leiningen (3)
- # lsp (21)
- # luminus (2)
- # malli (13)
- # membrane-term (1)
- # music (1)
- # nrepl (3)
- # off-topic (38)
- # pedestal (2)
- # polylith (39)
- # re-frame (33)
- # reagent (7)
- # releases (1)
- # remote-jobs (4)
- # rewrite-clj (28)
- # ring (21)
- # sql (2)
- # tools-deps (23)
- # vim (4)
- # xtdb (15)
hello, when i should use a -SNAPSHOT
version for a project? i have 3 projects, and 1 of them is dependency to both , they are under active development, not well tested etc
Are you using Leiningen or the Clojure CLI to do development/JAR building?
The CLI (`deps.edn`) supports both local (filesystem) and git deps so you don't need anything published to Clojars -- you can just depend on the unpublished versions.
I think Leiningen has checkout dependencies that let you do something similar.
If you publish SNAPSHOTs, the dependency management system (in lein
or clojure
) is not going to check for updates every time, as I recall, so it is harder to work with development projects with SNAPSHOTs anyway.
thank you so i will just use github? and people will find it from github? and deploy nothing on clojars?
The other downside to SNAPSHOTs is that a lot of people won't use any libraries that have dependencies that are SNAPSHOTs so you'd have to do non-snapshot releases of them all if you release JARs for other people to use.
if you don't need public access, you can test locally with lein by using lein install
which will install the library in your local maven repository
Yes, it's common with deps.edn
and the Clojure CLI to get libraries direct from GitHub with nothing published on Clojars. Less common with lein
(because it's not so good for working with git deps etc).
In general, you use SNAPSHOT versions when you want to share something that is still in progress. To answer your questions about overwriting: • non-SNAPSHOT versions are immutable - you cannot overwrite them when deployed • SNAPSHOTs are really a pointer to a timestamped version. So you can deploy a new SNAPSHOT of the same version, but under the hood that is a timestamped version that the SNAPSHOT version points to. For example, here are the timestamped versions for a SNAPSHOT version: https://repo.clojars.org/com/flipkart/aesop/runtime-snapshot-serializer/1.1.0-SNAPSHOT/
lein install
is still a clunky manual process compared to proper local filesystem dependencies.
@U06SGCEHJ @U7RJTCH6J Remind me, when/how often does lein
check for an updated SNAPSHOT? Is it just once a day?
my projects are leinengein projects, would like to use github dependencies but i dont know how
You can pin to a timestamped SNAPSHOT if you want build stability, since it is immutable (for example, using 1.1.0-20150327.093713-4
instead of 1.1.0-SNAPSHOT
for that examlpe
right, but learning a new tool and reconfiguring all your projects can also be clunky. I think deps.edn
does help with these types of workflows, but I'm also aware that changing tools is non trivial
if deps.edn
and the Clojure CLI, are better way i can read those. anyway thank you for the information
I think there are lein plugins that work with git dependencies, but I haven't tried any of them and I'm not sure how easy it is. With deps.edn
, it is possible to do a combination of local/git on your machine and publish snapshots to clojars as needed
@U68Q5G1BJ Re: lein
and github -- that's why I said:
> The other downside to SNAPSHOTs is that a lot of people won't use any libraries that have dependencies that are SNAPSHOTs so you'd have to do non-snapshot releases of them all if you release JARs for other people to use.
I wasn't suggesting you try to let others use your libraries via GitHub -- I was just offering that as an option for you while you are developing and still evolving your libraries. lein checkouts
is apparently a common approach for using checked-out git repos locally (via symlinks) when you're working on multiple libraries in parallel like that.
(I don't have any details -- I stopped using Leiningen six years ago -- but I remember people talking about that approach)
The #leiningen channel might be helpful if you want to dig into checkouts
(apologies for Lazarus’ing this thread) this is a good use case for http://jitpack.io (which supports Leiningen, amongst other build tools).