Clojurians Log v2

@seancorfield To package Clojure for Ubuntu, then I'd suggest a personal package archive (PPA), new release of Clojue can be pushed to this as soon as they are ready. There is a specific process for creating package to learn. Packages can be built for each release of Ubuntu (e.g. current long term support and intermediate releases) and published on the PPA. The relevant packages can be submitted for each new Ubuntu release (6 month cycle). There are also other options such as snaps and flatpack, but a proper *.deb package is much nicer in my opinion as it ensures there are no conflicts with other software installed via the package manager. There is a Leiningen package for Ubuntu, so some of the experience from that can be used. For Arch, I seem to remember that @dharrigan packages up clj-kondo , so I assume his work can be of help for packing to the Arch User Repository (AUR).

No, clj and tools.deps were developed together

@alexmiller so far very positive changes. I like that -M feels similar in concept to the :main in Leiningen, in part easing the move from Leiningen to CLI tools. My current thoughts are around edge cases where I have multiple aliases containing :main-opts and how to use them together with certainty rather than optomism. I have tried to elaborate some options in this gist https://gist.github.com/jr0cket/6fae7576a87d5d32eda4be2253f41692

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.

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.

@jr0cket Multiple aliases containing :main-opts is an "issue" today (stable) as well as tomorrow (prerelease), and the answer is the same as it has always been -- per the documentation -- "If multiple maps with these keys are activated, only the last one will be used" -- see https://clojure.org/reference/deps_and_cli#_aliases which explains how each different type of option is "merged" when multiple appear. The same wording is present in the prerelease reference docs, but spread out over multiple sections, rather than gathered together in one section.

Is that not "certainty" enough?

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

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

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.

didn’t realise that 🙂

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.

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

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

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

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

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

@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>
    &lt;url&gt;<http://mycompany/nexus/content/repositories/releases>&lt;/url&gt;
  &lt;/repository&gt;
  &lt;snapshotRepository&gt;
    &lt;id&gt;snapshots&lt;/id&gt;
    &lt;url&gt;<http://mycompany/nexus/content/repositories/snapshots>&lt;/url&gt;
  &lt;/snapshotRepository&gt;
&lt;/distributionManagement&gt;

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

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

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

That's right, I do maintain a few Clojure packages on Arch, like clj-kondo, babashka, clojure-lsp. A pleasure to do so 🙂 However, the main Clojure package is part of the Community Repo that is under a different maintainership. It is reguarly updated (last update was 2020-08-26, which brought in Clojure 1.10.1.645).

@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

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

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

@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

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

I meant this: https://github.com/seancorfield/depstar/blob/develop/src/hf/depstar/uberjar.clj#L150

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

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

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

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

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

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

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

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

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

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

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

(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?)

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

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

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

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

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

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

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

(I also tried nil)

You need an alias to use :override-deps

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