Clojurians Log v2

Now I'm playing with invoking antq.core as a "task" that system-exit call is brutal with no way to get around it. Although, I haven't checked if there's a more friendly exec entry point?

> Having a way to pass credentials explicitly would help. Can you clarify in which path you'd want to pass those credentials?

I could see having a flag about whether to strip snapshots?

I think the current antq behaviour is that if you are on a SNAPSHOT release, it assumes you are interested in the latest SNAPSHOT releases. Otherwise it will tell you about the latest non-SNAPSHOT release.

| :file    | :name             | :current        | :latest         |
|----------|-------------------|-----------------|-----------------|
| deps.edn | polylith/clj-poly | 0.3.32-SNAPSHOT | 0.3.34-SNAPSHOT |

| :file    | :name             | :current | :latest |
|----------|-------------------|----------|---------|
| deps.edn | polylith/clj-poly | 0.3.32   | 0.3.33  |

Maybe for the first case, showing both the non-snapshot and the snapshot release could be nice. But I don't think you are redesigning antq at this point, just porting it?

@alexmiller E.g. with find-versions , coord-deps, resolve-deps, etc. it would be handy if it could be passed along with :mvn/repos:

{:mvn/repos {"nexus" {:url ""
                      :username "..." :password "..."}}}

e.g.

{:mvn/repos {"nexus" {:url ""}}
 :mvn/credentials-fn (fn [repo] {:username "..." :password "..."})}

Putting creds directly in deps.edn seems like a bad idea security wise as those get committed to source

Yes, but a user would not put them there, it's just a way to pass them along for projects that want to use tools.deps for non-deps.edn things, like antq does to compare libs for project.clj

The credentials-fn would be a safer way I guess, that won't push people into the direction of putting credentials in deps.edn

but it opens other problems like putting code in deps.edn, which must be resolved and evaluated. can you more precisely point at where antq actually runs into this?

Nothing should be added to deps.edn by anyone, ever. Let me try to explain this better. Antq could be re-using more of tools.deps but it currently doesn't because tools.deps only assumes deps.edn + settings.xml (for username/password). What antq does for example is resolve username/password from project.clj with e.g. this:

:repositories [["nexus" {:url ""
                           :creds :gpg}]]

what is the maven stuff it's calling that could be done via tools.deps?

feel free to just point me to the code

the MIMA apis already cover explicit settings, but I might need to open some path for it

Yeah. It's mainly this thing. https://github.com/liquidz/antq/blob/01afc633a188c7bb90f1421eb8d95123df4aa2f0/src/antq/ver/java.clj#L21-L31 And resolve-deps, coord-deps, if they received settings, then other stuff could go away too. Let me fetch those links as well.

Correction, the last two (resolve-deps, coord-deps) already go through tools.deps, that one isn't custom But I guess it can't use a private repo today (when using lein for example) so it would still be useful if you could pass your own settings

just to be clear: I'm not advocating :settings to be some Maven specific object (bb does not depend on this), just regular data

or maybe it could be an opaque object as long as there a API-stable clojure function to create it from data

hopefully it made sense, if not, let me know

this is particularly the area where mima is just better than using the maven stuff directly - it has a sane approach to providing the environment around the resolver

yeah probably. but in bb I want people to use tools.deps as the API for doing "deps" stuff :)

and you are already using MIMA right