I want to include a local/root dependency, passing in an alias (so that it includes some extra-paths defined in that project). I recall this being a feature that was talked about but not yet implemented, but I can't find the ticket/ask clojure question/discussion ... Is this done? Can someone point me in the right direction? Or am I barking up the wrong tree?

Has not been done

https://ask.clojure.org/index.php/7843/allow-specifying-aliases-coordinates-that-point-projects?show=7843#q7843

I’ve often wondered about having something like that. I guess it might want to be constrained somehow, so a published deps.edn file can state which of its aliases are to be exported?

I would love to have aero like tag literals. stuff like #include #merge #env #join #profile #ref etc, seems that it could solve 99% of these kind of uses cases where some sort of composition is required

Personally I think it makes sense for deps.edn to always be fully resolved, and not require interpretation. Though arguably some of the features like :paths accepting aliases, are implementing a constrained version of #ref You can of course already use aero to generate deps.edn. Indeed this is something I was meaning to ask with regards your deps-modules tool… why not just use aero?

because clj / tooling doesn't know how to handle it

the ultimate goal was to have the less friction for devs

the stuff you generate/modify should be a normal deps.edn file, what you see is what you get

it's difficult enough to push deps usage when everything works fine (to some extent) with lein

wysiwyg bit is actually a counter argument to aero style tags 🙂 but if it was part of tools-deps it'd be ok

one thing for sure, if we have to tell devs who are happy with lein that they have to juggle with tons of aliases to get stuff going they ll be resisting the change

(personally I just want to speed up dev when you juggle with tons of repos (esp. with deep deps trees), the fact a commit is immediately available from repo a to repo b is the big sell, no need to wait ci/build/deploy from other prs)

the rest is sugar on top

Yeah — generating deps.edn from templates certainly isn’t without its problems… Though arguably tools.build substantially reduces the need to do that

clearly, I hate it, but it's "the least worst" solution imho so far

if we had #include/#refs the version pinning problem solved by deps-modules would be solved

include the version file in some internal key in your deps.edn files then #ref to the values you need for coords

you could also share aliases from one file to N other files in the "monorepo"

I think there’s a risk it muddies the water around what subset of deps.edn is available in a local project and at deployment. #include seems dependent on the context.

I am not sure I follow

What impact does putting a provided-scope dependency in the pom for a project and not the deps.edn in order to list an optional dependency? The provided scope dependency in this case would be to allow cljdoc to document my project.

#include is quite static. If you want to do conditional includes you can use stuff like profiles (in theory), or use aliases 🙂

This has been discussed before btw, you can find some conversation if you search this channel with "interpretation" or so. It was decided against then.

the risk is to end up in a situation where you're half way to have "deps.clj" where it's all clojure code anyway, then you can launch a rocket in space and merge your deps

@borkdude I guess it's still unsolved

@suskeyhose you can also provide a dependency scope in deps.edn afaik

no, you cannot

I was looking in the docs and I didn't see that, so I figured I'd have to put it in the template pom.

provided scope in a clojars dep should not pull in a dep with any tool

oh hmm, well if Alex says you cannot, it is true :) perhaps use an alias?

(I was mixing it up with :exclusions which you can provide)

what's the reason not to do this with an alias...?

Basically I have a project which requires a namespace from a library I don't depend on so that I can optionally extend that library to work with mine. cljdoc chokes on this because it's trying to analyze the namespace with a require for something not on the classpath, but if I specify a provided-scope dependency in the pom then it will include it on the classpath to allow analysis.

I can't do this with an alias because cljdoc is dependent entirely on the maven release and ignores the deps.edn

Hello when I'm trying to run "clj" from the CLI I get this: Error: Could not find or load main class clojure.main Caused by: java.lang.ClassNotFoundException: clojure.main

if anyone has feedback today on https://clojurians.slack.com/archives/C6QH853H8/p1636065875105900, please let me know!

is there a way to specify a git SHA for a :local/root dep?

not as a local dep

it might be possible to use a git local url and a git sha as a git dep

but I have not tried it

if it doesn't work, feel free to file a bug at https://ask.clojure.org

from a quick perusal of code and a couple tests, I think this won't work right now, but could easily be made to work

yeah one thing I ran into fairly quickly was the requirement that paths be relative rather than absolute (inherited from clojure.tools.gitlibs based on the stacktrace)

I can file a full report if you like

that's really a subset of the problem - the code that translates git urls to cache dirs and libs doesn't handle either raw paths or relative urls

but yeah, that would be great

will do ✔️

it seems like the URL issue is complected with the SHA issue; I will file separate issues for each

what's the sha issue?

https://ask.clojure.org/index.php/11250/using-a-git-sha-for-a-local-git-dependency https://ask.clojure.org/index.php/11251/allow-absolute-paths-for-file-based-git-urls

yeah, I don't expect to support shas for :local deps

if you want to treat something as a git dep, it will need to be a git dep

ah, I see - so really the SHA issue takes care of itself if the URL issue is fixed. Feel free to close the first one then.

yeah

git also supports local file support right?

git clone /srv/git/project.git

https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols (see Local Protocol)

doesn't work

well, doesn't work with absolute paths or relative .. paths (although it might work in some cases, it's doing unholy things to the gitlibs dir)

right

all just a matter of fixing the url -> cache-path function, which is a bit of a hack anyways

I see now that is the second issue, sorry for not paying attention

trying to decide how far I want to go to unhack it :)