Clojurians Log v2
tools-deps
Interestingly, if I just comment out the dependency on org.apache.httpcomponents/httpcore "4.4.5" everything works and it still comes in as a transitive dependency of something else... Weird.
it would be useful to know the original set of deps that failed
that UnresolvableModelException implies to me that we're running into trouble reading that pom file somehow
org.apache/apache "13" seems to be problematic, but I don't know why that would be requested when the httpcore dep is a top-level dep but not when it is a transitive dep of something else. This was kind of a weird edge case and it's hard to isolate to a repro case because it relies on some context from our monorepo setup. If I get time, I'll try to boil it down to something small but I have a workaround for now so it's not terribly important.
(when I tried to boil it down to a simple repro case, I couldn't -- it just started working)
There is some filtering in the transitive dep stuff, it’s possible it’s getting filtered out
If you're splitting on newline, won't that break for newlines instead of spaces? 😄 Are newlines encoded somehow then decoded before going to args?
well that didn't work before, and still doesn't work, but I think is a much less sensible thing to want to do
We're running into this warning at work:
WARNING: Specified path is external to project: ../activator/test
WARNING: Specified path is external to project: ../affiliate/test
WARNING: Specified path is external to project: ../api/test
WARNING: Specified path is external to project: ../auth/test
WARNING: Specified path is external to project: ../build/test
...the recommended way is to not do that :)
this is a step towards eventually making this an error
but I will take a note to think about this particular case of accessing the test src of a project - I've had past convos where we talked about ways to include a dep + activate an alias in the remote project as you interpret it which could be one way to do this with local deps instead (local dep + include a test alias to grab its test paths). but needs a lot more thought.
Given that several of these pain points seem to relate to mono repos, I vote that you be made to work on a mono repo for a few months 😁
or everyone else should stop working on mono repos... :)
I have worked on them in the past. did not like, would not mono repo again.
So, if you were forced to work in a monorepo and you could set up deps.edn however you wanted, how do you think you might approach it? I'm hoping for some insight that gets us closer to a "standard" CLI/`deps.edn` approach that isn't going to get pulled out from under us...
Having a single deps.edn in the top-level perhaps? With an alias for each subproject that brings in just that subproject's paths/deps?
yes, I think at top level
OK, I might try switching us to that setup and see what pain points I run into. My immediate thought is that running a REPL in the "everything" context would then require a lot of aliases (one for each subproject -- about three dozen for us right now) or would require duplicating the content of aliases into the :everything alias.
I don't think that will work with :local/root since each subproject would still need a deps.edn file for its own dependencies -- unless you duplicate everything up into the master deps file... and that's a lot of duplication...
I started down this path to see what it might look like but ran into the :local/root issue pretty much immediately. Happy to screen share with you at some point to try to hammer some of this out.
I guess we could move our "everything" subproject to effectively be the top-level folder above all those other subprojects, so all paths within them would be within the overall "project"? Not sure what other weirdness that would cause though since we rely on :local/root a lot and currently can guarantee that all subprojects can depend on each other by using `:local/root "../<subproject>" URLs...
Yep, I saw this one too today
"external to project, but within monorepo, so still okay?"
My use case for this is to compensate for the fact that a generated pom.xml file does not include the source folders, so I'm adding add that manually using :paths
For us it's about adding test folders "manually" but, yeah.
I understand why the warning is given -- having :paths outside the project should be a red flag in general -- but I'm not sure what the recommended approach should be for dev/test in a large monorepo...
Looking deeper into it, we now ported that lib to deps.edn as well, so we don't need the pom.xml anymore :) Just local/root works now (we did local/root pom + paths before)
Cleaned that up, so problem solved for us