This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-06
Channels
- # announcements (18)
- # asami (14)
- # aws (5)
- # babashka (58)
- # beginners (32)
- # calva (12)
- # cider (29)
- # clj-kondo (8)
- # cljfx (8)
- # cljs-dev (4)
- # clojure (101)
- # clojure-europe (54)
- # clojure-germany (5)
- # clojure-nl (8)
- # clojure-serbia (8)
- # clojure-spec (12)
- # clojure-uk (8)
- # clojurescript (24)
- # cursive (3)
- # datomic (17)
- # docs (2)
- # etaoin (12)
- # events (1)
- # fulcro (1)
- # google-cloud (2)
- # jobs (1)
- # jobs-discuss (6)
- # lsp (65)
- # luminus (2)
- # malli (10)
- # meander (4)
- # nrepl (1)
- # off-topic (112)
- # onyx (2)
- # pathom (6)
- # polylith (14)
- # re-frame (9)
- # reagent (36)
- # reitit (13)
- # releases (2)
- # remote-jobs (5)
- # rewrite-clj (12)
- # shadow-cljs (70)
- # specter (2)
- # startup-in-a-month (1)
- # xtdb (14)
I’m just curious about a thing. Do users of the poly
tool use the latest version of tools.deps
and live with the warnings you get, or do you use an older version? ( @allandaviesza and others)
We'll modify our project once the version of the poly tool that is kinder to tools.deps
is released
Yes, I’m currently working on it @allandaviesza in the issue-66
branch. The tool will be backward compatible with the current tools.deps format, so that you can go back in time with git checkout
and still view older versions of the project and use commands like info
,`libs`and deps
. I will modify the current poly-migrator
tool so that it can migrate from :toolsdeps1
(which is what I call the current version in the code) to :toolsdeps2
(next version) which will support the new format that uses :local/root
when specifying the bricks in a project. I also realised that it would simplify the migration from the old Leiningen version if the tool could read that format too, which is almost fully implemented in the issue-66
branch. A result of this is that people who still use the old Leiningen based version can use all commands in the poly
tool except the create
command, and when migrating to the new version, the old code can still be visualized by the poly
tool, which I think is kind of cool.
sounds great!
It would also be interesting to hear more about your experience with Polylith so far.
hey folks!
I came across polylith and decided to give it a try by migrating one of our microservices to use it (hopefully the others will follow 🙂 ). I was able to setup a workspace and put everything under a base
from our project and tried to run the tests with clojure -M:poly test :all :dev
but I got the following error
Unknown library type: git
which is coming from https://github.com/polyfy/polylith/blob/issue-66/components/test-runner/src/polylith/clj/core/test_runner/core.clj#L15 (I’m using Sean’s project as a base) and caused by the fact that one of the project’s deps is defined using git/url
in deps.edn
.
My the question would be that it is possible to use git deps with polylith
or it is against the principles and these should be migrated to be a component
?
Hi @UBS3FD77A and thanks for reporting this problem. This is something that I expected to work! We will have a look :-)
Okay, great! And as a side note. The issu-66
is not 100% production ready, and I will make some breaking changes in the inner format (what you get when executing e.g. poly ws out:ws.edn
) so if you start using it from that branch, then the output of this file will change a bit over time + small refactorings of the workspace.edn
config file will also happen. But for people who only work from the master
branch, a migration tool will take care of all this the day the branch is merged/released to master
.
Hi, I spotted great piece of work here and I just created https://aur.archlinux.org/packages/polylith-bin/ for ease installation for those using ARCH Linux distro.
Nice that you like Polylith, and thanks for contributing to it!
@U11EL3P9U Helped me a bit with polishing it. Thanks!