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

Or patchsets etc

http://ask.clojure.org

Thanks

https://ask.clojure.org/index.php/12005/tools-deps-integration-with-sourcehut

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

...it 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.

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".

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...

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?

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 🙂 )

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?

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

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.

i can imagine.

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.

@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.

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.

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!)

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.

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.

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)