Fork me on GitHub
#beginners
<
2021-06-22
>
West01:06:04

Even on a rolling release?

dpsutton01:06:03

Don’t know what that is. But if it uses the “package” version you cannot use the handy upgrade/downgrade feature of lein itself. And that’s what is occasionally useful

echristopherson01:06:45

rolling release = a distro that just gets package updates continuously, not twice a year or whatever

andy.fingerhut01:06:00

The Leiningen upgrade/downgrade, if installed via Leiningen's own methods vs. some Linux distribution's package manager, seems to me to work regardless of that distribution's package update policies. There is no need to rely on, or wait for, anyone else to create a package for newer (or older) versions of Leiningen. I agree it isn't "just like every other package" you tend to install, but it is about as flexible as you can get, if you care which version you are running. I think I've typically got about 10 versions of Lein installed on my system at any given moment, which takes only a few KBytes of disk space the way it is packaged, since it is only a small shell script. Only the larger JAR files of the Lein versions I've actually used on the system get downloaded.

seancorfield04:06:01

Sounds a bit like me with the Clojure CLI:

seanc@DESKTOP-30ICA76:~/oss$ ls -d /home/linuxbrew/.linuxbrew/Cellar/clojure*
/home/linuxbrew/.linuxbrew/Cellar/clojure             /home/linuxbrew/.linuxbrew/Cellar/[email protected]
/home/linuxbrew/.linuxbrew/Cellar/[email protected]  /home/linuxbrew/.linuxbrew/Cellar/[email protected]
/home/linuxbrew/.linuxbrew/Cellar/[email protected]  /home/linuxbrew/.linuxbrew/Cellar/[email protected]
/home/linuxbrew/.linuxbrew/Cellar/[email protected]  /home/linuxbrew/.linuxbrew/Cellar/[email protected]
/home/linuxbrew/.linuxbrew/Cellar/[email protected]  /home/linuxbrew/.linuxbrew/Cellar/[email protected]
/home/linuxbrew/.linuxbrew/Cellar/[email protected]  /home/linuxbrew/.linuxbrew/Cellar/[email protected]
/home/linuxbrew/.linuxbrew/Cellar/[email protected]  /home/linuxbrew/.linuxbrew/Cellar/[email protected]
/home/linuxbrew/.linuxbrew/Cellar/[email protected]  /home/linuxbrew/.linuxbrew/Cellar/[email protected]
/home/linuxbrew/.linuxbrew/Cellar/[email protected]
(and I think I have even more versions installed on my main system!)

seancorfield04:06:40

(! 503)-> ls -d /usr/local/Cellar/clojure*
/usr/local/Cellar/clojure               /usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]
/usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]
/usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]
/usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]
/usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]
/usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]
/usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]
/usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]
/usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]
/usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]
/usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]
/usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]
/usr/local/Cellar/[email protected]    /usr/local/Cellar/[email protected]

Jakub Šťastný15:06:44

What Java do people use to run CJ/CLJS projects? I was confused about the JVM implementations, but I understand that OpenJDK is actually the original thing from Sun/Oracle? What version is recommended? Always the newest one? I can see there are many openjdk-* packages in Ubuntu. (I installed openjdk-16-jre-headless for now.)

Alex Miller (Clojure team)15:06:20

OpenJDK is the open source GPL core, Oracle releases it's own derived from that + some extra stuff plugged in

Alex Miller (Clojure team)15:06:10

most of the variants are built from the same OpenJDK core, except for the IBM j9 vm, which is a different impl

Alex Miller (Clojure team)15:06:13

there are both "LTS" (long term support) versions and intermediate releases without that. With Clojure, we recommend using an LTS version if you don't specifically need something from a newer version. The last 2 LTS versions were 8 and 11. 17 will be coming out this fall and will be the next LTS version.

Alex Miller (Clojure team)15:06:41

So we would currently recommend 11 (but other versions work too, including 16)

Alex Miller (Clojure team)15:06:18

I would actually recommend using the jdk (development kit) though, not the jre (runtime engine), as it includes tools you will find useful.

Jakub Šťastný16:06:36

Thank you @U064X3EF3. So to be clear, when you say LTS, you are referring to LTS version of OpenJDK? Which in Ubuntu would then be openjdk-11-jdk-headless I reckon?

Jakub Šťastný16:06:31

Perfect :thumbsup: Cheers!!!

Alex Miller (Clojure team)16:06:28

All non-LTS versions should basically be considered dead (except the latest), so I would NOT use 9-10, 12-15

Michael Stokley15:06:47

empty collections are truthy in clojure. does that mean folks are more likely to have a function return either a non-empty collection or a nil? as opposed to staying within a narrower type and always returning a collection (of a given type), whether empty or not

indy15:06:36

not-empty is handy in such cases. Let the particular contexts handle it the way they want than deciding truthiness or falsiness beforehand

Michael Stokley15:06:09

thanks! i greatly prefer not-empty over seq

dpsutton15:06:07

quite common to call seq on collections as return values to probe this. Often return a collection and let the caller care about whether it has any values in it

🙏 2
Michael Stokley15:06:49

that seems consistent with what i perceive to be a general preference for avoiding nil in clojure

dpsutton15:06:39

i don't think there's a general preference for avoiding nil. but that gets close to style and personal preference

Michael Stokley15:06:50

oh, that's interesting. what about place oriented programming and all that? {:a nil} vs {}?

Michael Stokley15:06:02

i thought for sure the language convention was to omit a value instead of saying explicitly "this value is absent" via a nil

dpsutton15:06:56

generally true to not put nil values in a map. I was just talking about shying away from nil as a value in general.

tschady19:06:06

in what namespace do y’all put your integration tests? I was just going to go with test/<package>/integrations/, but wondering if any tools look for something standard

salam06:06:46

i'm not sure if there's any convention but here is how i organize my test directories:

❯ tree test 
test
├── acceptance
│   └── shell
│       ├── api_server_test.clj
│       └── cli_app_test.clj
└── unit
    ├── core
    │   └── domain_test.clj
    └── shell
        └── utilities_test.clj

5 directories, 4 files
and i would override the default test alias in deps.edn with {:extra-paths ["test/acceptance" "test/unit"] so that tools like Cursive can find these directories and automatically mark them as "Test Sources Root", which in turn enables other useful Cursive features (e.g., jumping between production and test namespaces, automatically creating test namespaces in the right directories via shortcuts, etc.) this layout also works well with test runners such as Kaocha so that you will be able to run a particular kind of tests by specifying an id that maps to a directory:
#kaocha/v1
{:tests [{:id :unit
          :test-paths ["test/unit"]}
         {:id :acceptance
          :test-paths ["test/acceptance"]}]}

tschady13:06:18

awesome point about kaocha ids, thanks!

seancorfield20:06:53

I don’t there’s any particular convention for that, TBH.