Is that possible to send package from GitHub? like for npm https://medium.com/faun/automate-your-npm-publish-with-github-actions-dfe8059645dd ?
I would expect this to be possible since lein
, boot
, and CLI/deps.edn
all have ways to build an uberjar and publish it to Clojars. (for the latter, see https://github.com/clojure/tools.deps.alpha/wiki/Tools – I use https://github.com/seancorfield/depstar and https://github.com/slipset/deps-deploy for build/deploy)
Another issue is how to authenticate? npm has tokens for publishing packages. Does Clojars provide tokens as well?
or maybe using password…
$ env CLOJARS_USERNAME=username CLOJARS_PASSWORD=password clj -A:deploy
I use meyvn for deploying by the way.
Turned out Meyvn turned into a closed software in newer version…
root@018f6774f5b1:/bin# clj -Sdeps '{:deps {org.danielsz/meyvn-installer {:mvn/version "1.2.1"}}}' -m meyvn-installer.core
You will need the username/password that came with your licence. Are you ready to proceed? Y(es) or N(o)?
N
Would you like to apply for a licence? Y(es) or N(o)?
N
Bye for now.
I got lots of thing to migrate if deps-deploy
is available. But I’m not sure if there’s a cheap way to generate the pom.xml
file that deps-deploy
. Damn Clojars(maybe it’s maven to blame), I never feel deploying Clojure packages is as simple as deploy npm packages.
depstar
helps, I created a lilac.jar
file with it. But I still got some confusion, the generated jar file is quite large:
root@6af2038f8c8d:/tmp/lilac/target# du -ah lilac.jar
4.5M lilac.jar
as I extracted it, I see lots of file under clojure/
:
root@6af2038f8c8d:/tmp/lilac/target# jar xvf lilac.jar
created: lilac/
inflated: lilac/router.cljs
inflated: lilac/main.cljs
inflated: lilac/util.cljs
inflated: lilac/test.cljs
inflated: lilac/core.cljs
inflated: lilac/core.clj
created: clojure/
created: clojure/asm/
created: clojure/asm/commons/
created: clojure/test/
created: clojure/instant/
...
root@6af2038f8c8d:/tmp/lilac/target# ls -p
clojure/ lilac/ lilac.jar
Since I’m packaging a ClojureScript package, can I remove them from my jar?
That sounds like you made an uberjar instead of a library jar? You only use uberjar to create applications – for libraries that you deploy to Clojars, you should make a jar instead.
It’s true that clj -Spom
will only get you part of the way. It’s why clj-new
now produces fully-fleshed out pom.xml
files in new app
, lib
, and template
projects. See GitHub - seancorfield/clj-new: Generate new projects based on clj, Boot, or Leiningen Templates! onward for a discussion of that.
Turned to depstar.jar
and it worked.
I ran into another issue that when my package finally loaded into shadow-cljs and it told me lilac/core.clj
was not find:
[:client] Configuring build.
[:server] Configuring build.
[:server] Compiling ...
[:client] Compiling ...
[:server] Build failure:
------ ERROR -------------------------------------------------------------------
File: jar:file:/Users/chen/.m2/repository/mvc-works/lilac/0.1.0-dev2/lilac-0.1.0-dev2.jar!/lilac/core.cljs
failed to require macro-ns "lilac.core", it was required by "lilac.core"
FileNotFoundException: Could not locate lilac/core__init.class, lilac/core.clj or lilac/core.cljc on classpath.
clojure.lang.RT.load (RT.java:462)
clojure.lang.RT.load (RT.java:424)
clojure.core/load/fn--6839 (core.clj:6126)
clojure.core/load (core.clj:6125)
clojure.core/load (core.clj:6109)
clojure.core/load-one (core.clj:5908)
clojure.core/load-one (core.clj:5903)
clojure.core/load-lib/fn--6780 (core.clj:5948)
clojure.core/load-lib (core.clj:5947)
clojure.core/load-lib (core.clj:5928)
clojure.core/apply (core.clj:667)
clojure.core/load-libs (core.clj:5985)
clojure.core/load-libs (core.clj:5969)
I went to ~/.m2/
and find the package of the specific version, the file lilac/core.clj
existed:
=>> c 0.1.0-dev2/
_remote.repositories lilac-0.1.0-dev2.jar lilac-0.1.0-dev2.pom
=>> jar xvf lilac-0.1.0-dev2.jar
created: lilac/
inflated: lilac/main.cljs
inflated: lilac/test.cljs
inflated: lilac/router.cljs
inflated: lilac/util.cljs
inflated: lilac/core.cljs
inflated: lilac/core.clj
created: META-INF/
inflated: META-INF/MANIFEST.MF
created: META-INF/maven/
created: META-INF/maven/mvc-works/
created: META-INF/maven/mvc-works/lilac/
inflated: META-INF/maven/mvc-works/lilac/pom.properties
inflated: META-INF/maven/mvc-works/lilac/pom.xml
In my original project https://github.com/mvc-works/lilac/tree/deps-deploy I have two folders src/
and macros/
, and lilac/core.clj
locates in macros/
folder. Pretty confused if that would cause problems.
Updates:
I reran shadow-cljs but the error is missing… now I’m bit confused…
I’m not quite sure what the behavior should be (for cljs) when you have both file.cljs
and file.clj
. Someone familiar with ClojureScript and macros will hopefully be able to answer that.
At least it’s working for now. The package got deployed https://github.com/mvc-works/lilac/runs/436699319?check_suite_focus=true .
Thanks for the help.
I just published a small lib intended to streamline the common release flow for small libraries that use tools.deps: https://github.com/appliedsciencestudio/deps-library
The motivating use case is publishing versioned releases of small & simple libraries without having to have to configure three different tools every time.
It’s just one day old, & open to feedback.
Looks cool? It looks like the version is related to git tags. But how do you decide the versions from tags? And would it work properly if that runs in CI environments?
Also a more general question… I’m quite wondering why group-id
and artifact-id
are not inside deps.edn
, like package.json
in Node.js . Package management being a core feature of the whole ecosystem seems not being enhanced enough.
Versioning is managed by garamond, which bumps the tag (looked up from previous tags in git) based on the increment you pass (patch, minor, or major).
It works well with CI - I use it for js-interop and have a workflow triggered when I push a new tag: https://github.com/appliedsciencestudio/js-interop/blob/master/.circleci/config.yml#L63. (Requires git push --follow-tags
)
I’m not familiar with accepted practices or recommendations for adding new keys to deps.edn. Is that a thing? I’m not convinced the release.edn
approach is best, but it seemed like a reasonable place to start.
Personally I prefer specifying a version by myself, since I have to create PRs and I need tags like 0.1.1-a1
before it’s being merged.
I’ve just released 0.2.0
with support for passing a -v
or --version
flag to tag/release an arbitrary version. Eg/
clj -A:release -v 0.1.1-alpha.1
there is also a --dry-run
flag which will tell you what’s going to happen (eg. when passing --patch
) without performing any side effects.
Managed to publish my package to clojars. Super smooth compared to other solutions.(Meyvn used to such easy too very long time ago…).
I’m still feeling quite rough to have version in CLI. Is there are reason why it can’t be in reease.edn
?
great to hear!
I’ve just released 0.3.0
:
- lets you specify a
:version
inrelease.edn
- All options also be passed as command line args, so the
release.edn
file is optional.
Documentation in the readme: deps-library/README.md at master · applied-science/deps-library · GitHub
thanks
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.