Fork me on GitHub
#tools-deps
<
2020-09-06
>
hugod01:09:25

I like the new features. :ns-default and :ns-aliases look very useful. The -P option is great, and could be even nicer if it (optionally) output a map of the resolved dependencies, which could be used to make reproducible builds.

alexmiller01:09:59

Every build outputs a lib map in the cache dir with this info (-Sdescribe tells you where)

hugod01:09:08

didn’t realise that 🙂

hugod01:09:43

To be honest, I’ve always found the different merging rules confusing and never really understood their purpose. Why not just have -A to specify the aliases to merge, and -e, -x (equivalent of the :exec-fn key) or -m (equivalent of the :main-opts key) to specify or override what should be run. Maybe with a -r for a future repl specifier. If the config is not specific, define a precedence for :exec-fn and :main-opts. This would separate (decomplect, dare I say?) merging of aliases from specifying what to invoke, which I, for one, find simpler to understand.

seancorfield01:09:03

@hugod In the stable version, -M didn't pick up any items from the alias(es) except :main-opts and in the first version of -X on the prerelease track didn't pick up any items from the alias(es) except the fn/args spec as I understand it. In the latest prerelease, both of those pick up everything in the alias(es) specified and then -M runs the :main-opts while -X runs the function invocation -- and -A is slated for being similar (picking up everything in the alias(es)), but ultimately just running the REPL, not executing main/function stuff. That's why I proposed keeping -R and growing it to pick up everything in the alias(es) and just running the REPL -- -R for REPL. But, either way, it's a much more streamlined piece of logic: all three options pick up all options and then each one of -A (or maybe -R?), -M, and -X selects what execution model is used.

seancorfield01:09:33

It's nice and streamlined. And I think it removes a lot of confusion about which parts of an alias get picked up by which options.

hugod01:09:29

Having -M, -X, and -A pick up everything certainly seems like an improvement. I would still find it simpler to just have the one option for specifying aliases, and then options for specifying what to run. Using lower case for the latter would allow for the cli to maintain backward compatibility iiuc.

seancorfield01:09:13

I suspect there would be confusion, since -e, -m, and -r are existing main options today (for clojure.main).

seancorfield01:09:19

You'd also need to specify both an option to collect aliases and then an additional option to specify the action to take. With the prerelease direction, you'd only need one option: either -X for aliases and execute function, or -M for aliases and main function, or -A for aliases and the REPL (at some point, given -A currently still executes main opts).

hugod02:09:31

I was suggesting -e and -m kept their current meaning, and implied invoking clojure main.

seancorfield02:09:48

But :main-opts can contain a combination of those so I don't think that's going to be intuitive.

seancorfield02:09:05

(`:main-opts` can also contain -i and -r options)

mike_ananev04:09:43

@alexmiller Is it possible to add functionality of generation distributionManagement section to 'clj -X:deps mvn-pom' command? I need to distribute my artefacts written in Clojure to corporate Nexus. To do this I need section in pom.xml:

<distributionManagement>
  <repository>
    <id>releases</id>
    <url></url>
  </repository>
  <snapshotRepository>
    <id>snapshots</id>
    <url></url>
  </snapshotRepository>
</distributionManagement>
Building and deploying artefacts is performed in corporate Jenkins, where I can't manually add this section.

seancorfield05:09:03

@mike1452 Since clj -X:deps mvn-pom only updates dependencies and a few other bits, so what I tend to do is generate an initial POM, augment it manually, check it in to version control, then just run that command as needed to update the dependencies section (and it leaves all the rest intact).

seancorfield05:09:28

So you could manually add that section, and clj will not overwrite it.

vlaaad05:09:48

Weekly reminder that reading/updating pom.xml is a workaround for the problem, not a solution :)

☝️ 3
borkdude07:09:12

@alexmiller I know tools.deps isn't going to expand ~, but I'd like to know the reason for this. Reason I'm asking is that I'm considering doing this in .clj-kondo/config.edn and would like to know if I'm missing some problems

alexmiller11:09:24

Because then everyone reading deps,edn has to interpret the file

alexmiller11:09:31

It’s no longer just edn/read, it’s that plus run magic code

borkdude12:09:40

Why does it have to be interpreted by anything else than tools.deps which already does interpretation of this entire model?

borkdude12:09:17

I mean, merge, assoc, etc still works for other tools in this case?

alexmiller12:09:56

If you have alias data, anyone may be reading it via the basis (without tools.deps, which has a lot of deps)

alexmiller12:09:41

There are a bunch of tools already reading and manipulating deps.edn. The less they have to know, the better

borkdude13:09:12

I don’t think this will be a problem for the linter config file. Thank you sir.

mike_ananev09:09:19

@seancorfield Is it possible to exclude clj source files from uberjar using depstar? I need only aot compiled files in uberjar, when distributing it. Also, how do you recommend to compile java source files, when using depstar?

mike_ananev09:09:38

Is it possible to add to depstar something like this https://gist.github.com/just-sultanov/e2f61734e22e2ed3981216ed9b880bc0 to compile java sources?

borkdude09:09:40

@mike1452 depstar has this for removing itself: https://github.com/seancorfield/depstar/blob/a542560766cfd2b51d415908885625aa64165cb4/src/hf/depstar/uberjar.clj#L292 I think that can be easily extended to remove other things

borkdude09:09:37

Ah no, scratch that, that's only for removing something from the classpath.

borkdude09:09:02

Ah, and that's exposed via -X (not clojure's -X, but depstar's -X)

borkdude09:09:27

so probably something like -X "\.clj$" would work

dominicm12:09:27

You don't need to remove the clj files anyway. Or is there an additional piece of information?

seancorfield18:09:06

The regex-based file exclusion was added in the most recent depstar release @mike1452 -- did the suggestions above work for you?

seancorfield18:09:03

(you could also specify a classpath that only had the class path, without the src path I suppose, if every piece of source has been compiled?)

seancorfield18:09:00

As for Java, that's outside the scope of a Clojure tool: compile it yourself and then add that to the classpath (depends on how/where you compile your Java source to .class files).

dominicm22:09:13

How can I remove org.clojure/clojure from the classpath? I seem to recall a trick to it.

dominicm22:09:34

(I want to use org.clojure/clojure$sources instead)

alexmiller22:09:52

Just specify a different coord for it? Or use :override-deps?

alexmiller22:09:12

Keep in mind that everything calls clojure.main and you need a class for them jvm to invoke

dominicm22:09:47

I tried using override-deps, maybe I used it wrong.

dominicm22:09:52

Error building classpath. Coordinate type not loaded for library org.clojure/clojure in coordinate {}

dominicm22:09:35

(I also tried nil)

seancorfield23:09:36

You need an alias to use :override-deps

dominicm23:09:54

I used one. But I'm trying to override to remove it and {} didn't work at that removal coordinate.