Fork me on GitHub
Joshua Suskalo14:06:14

Where can I post to put in a feature request to make sourcehut git dependencies auto-resolve the url based on groupname the same way that github and gitlab do?

Joshua Suskalo14:06:38

And would a PR implementing this be likely to be accepted?

Joshua Suskalo14:06:35

Or patchsets etc

Joshua Suskalo14:06:19

For those unfamiliar with sourcehut (,, it's a git forge like github or gitlab that's focused on email-driven contribution, as well as being a high-performance, low-overhead forge.

Joshua Suskalo14:06:19

For those unfamiliar with sourcehut (,, it's a git forge like github or gitlab that's focused on email-driven contribution, as well as being a high-performance, low-overhead forge.

Drew Verlee23:06:35

So based on this ticket i'm assuming that deps.edn :paths doesn't resolve paths outside the directory e.g "../foo"


I think it still works but you'll get a WARNING that it will go away at some point...

👀 1
seancorfield23:06:15 may have already gone away (I stopped doing :paths outside the directory where deps.edn is a long time ago so I don't know for sure @U0DJ4T5U1)


But it is why Polylith went through that massive change last year.

Drew Verlee23:06:35

if i do -Spath it it still shows up. I don't want this to be a long term solution.


What still shows up? The WARNING? If so, your project needs to stop using :paths outside the "project".

Drew Verlee23:06:57

The path still shows up in the output


Yeah, so it hasn't been made illegal in t.d.a yet.


Like I said, I wasn't sure -- I stopped doing it last year to avoid the WARNING 🙂


What exactly is your question? I'm confused at this point...

Drew Verlee23:06:08

To give context, there is a macro which reads a file and turns it into something the browser client thats being built needs. In the console logs that variable is "nil". Which means either it's nil in the cljs context but is getting read correctly (i feel like i need a whiteboard explanation). Or that file isn't getting read because the path isn't valid. I think it's the later and i'm about to sanity check it by trying something simplier.


You have a macro that reads a file at expansion time? That's a bit... dangerous...


But I'll assume your macro is attempting to read a file from the classpath so it's using io/resource, yes?


And your deps.edn file has :paths (or :extra-paths) that contains a relative or absolute filepath that is outside the project?


(because if that file is inside your deps.edn project, all of this is irrelevant 🙂 )

Drew Verlee23:06:53

the project has a shadow-cljs.edn with :deps true and a deps.edn with a :deps {foo {:local/root "../bar"}} and that "bar" has a deps with with :paths "../resources" And yes that's awkward. The goal was to have Boot and deps co-exist for a bit so if there is a way to have boot do something like :local/root this would probably get easier and cleaner


Can you move that resources folder down into bar and update the Boot file to reflect that it moved?

Drew Verlee23:06:57

idk, that was going to be the next thing i tried 🙂

Drew Verlee23:06:05

That seems to do what i want, weather or not it's what i need.... will wait for another day! I hope to not be like this for very long 😆


Migrations from one tech to another can be a bit painful 🙂


I'm migrating a lot of legacy code into Polylith right now... it is tedious and frustrating at times.

Drew Verlee23:06:33

i can imagine.

Drew Verlee23:06:55

I have looked at polylith but i haven't had to manage an application that seemed complex enough to warrant more thought about organization so i never could wrap my ahead around the problem it was solving.


As far as I'm concerned, any repo that produces multiple application artifacts is a good candidate for Polylith.

Joshua Suskalo15:06:06

@U04V70XH6 is there somewhere that I can see the basic changes for that alteration of polylith? I've been using polylith for a monorepo for a while and we're using this style of deps at the moment.

Joshua Suskalo15:06:27

Oh wait, I think I see. This actually shouldn't be a concern because paths aren't being directed outside the current directory, only deps with :local/root target outside the current directory.


I'd say "read issue #66" and the associated code changes but it was a massive change early last year -- so it depends on when you started using Polylith? 🙂


We started using Polylith while that work was happening on a branch and so we started with :extra-deps instead of :extra-paths for :dev and used :local/root right from the start.


And that all came about because we had been on bleeding edge versions of the Clojure CLI / t.d.a for a while and saw it coming. This is the same reason we always update our vendored-in CLI to the latest prerelease versions, and update our repo to the latest Clojure prerelease versions: to test against upcoming changes so we aren't caught out when they drop.

Joshua Suskalo16:06:42

Yeah, looks like we started using it after the issue. The only place we're using extra paths is in the dev alias on the root deps.edn for the development project.


(I mention this because there are always people complaining at each new Clojure release about changes that happened in early alphas that they should have tested against and provided feedback on!)

Joshua Suskalo16:06:51

Yeah, I always try to stay on the bleeding edge to catch stuff like that.


"extra paths .. in the dev alias" -- because you have some Cursive users?


Using :extra-paths instead of :extra-deps means you also have to duplicate all the :extra-deps libs from bricks up into :dev as well which is a pain.

Joshua Suskalo16:06:01

After reading through the issue 66 it looks like another solution to this problem would be to make a #include "some-dir/blah" to allow you to read in arbitrary other edn data into the current file as a value. This would allow multiple edn files, one per project, while one large file at the root enumerates the projects. That way you can have a "working directory" of the root, but with separation of the data. That said, this adds complexity to the clojure cli that's definitely not necessary, and honestly I like having deps edn files in components as it allows specifying library dependencies of components with the component rather than needing to always include them in every project.


Pretty sure the core team wouldn't want to support #include or anything like that since it's meant to be "just EDN" with no custom readers. And it would be a terrible mistake for Polylith to add "proprietary" extensions to deps.edn because then you couldn't use any standard t.d.a tooling with those files.

Joshua Suskalo16:06:38

Yeah, agreed on both counts.


It frustrates me already that Polylith doesn't rely on t.d.a more and ends up having to re-implement stuff that t.d.a already supports (see the recent ticket about aliases in paths -- built into t.d.a but Polylith had to re-implement it b/c it doesn't use create-basis etc)