Clojurians Log v2

@ericdallo I created a PR for that newer version (1.12.217), since r-ryantm hasn't. Would you mind posting a nixpkgs-review comment on that one as well please? I also added myself as maintainer, so that I can use the merge bot to merge r-ryantm's ones in the future.

sure!

I've no urgent need for the update, just intrigued to play with the new TUI stuff in a toy project on nixos.

Perhaps @ericdallo know something about this?

I built locally and seems fine, also post the nixpkgs-review comment to help, but I think we need some maintainer to take a look

maybe ping them again

Thanks guys. As I said - idle curiosity rather than any immediate need - it's become part of my daily list of rationalisable-procrastination-activities (currently (-> self check-email check-clojurians check-nixpkgs-for-babashka-update update-emacs-packages work) )

This is why I don't generally rely on package managers for dev tools... Can you manually install it? Or does Nix try to override manual installs with its own stuff?

I can. Well, I can write my own flake for it (or more accurately, adapt what someone cleverer has already done for nixpkgs) -- we use direnv and a nix flake per repo to control our dev environments, so needs to tie into that. Haven't needed to track bleeding edge for babashka (nor do I now, really), so hasn't been an issue. Ideally the babashka repo would include a flake exporting an overlay for those who want to bypass the nixpkgs update cycle -- I'll add it to my list of less-immediately-rationalisable-procrastination-activities and could raise a PR for it when I get a chance?

I'm fine with hosting a flake wherever, as long as I don't have to use nix and don't have to maintain it. Keeping it in the bb repo probably would mean I'd have to maintain it

Understood - if I do get a flake sorted I'll just raise a doc PR against babashka linking to it so it's not your problem

An overlay is the easiest way to override the versions of a package IMO.

See https://github.com/Misterio77/nix-starter-configs/blob/main/standard/flake.nix#L43 and https://github.com/Misterio77/nix-starter-configs/blob/main/standard/overlays/default.nix#L9

So in this case the overlay would look something like:

final: prev:
{
  babashka-unwrapped = prev.babashka-unwrapped.overrideAttrs (
    finalAttrs: _: {
      version = "1.12.216";
      src = prev.fetchurl {
        url = "";
        sha256 = "sha256-rfHX5A4LaYxn5FEBQ+Niro1RFIfLT+lN2HfzQSg89mw=";
      };
    }
  );
  babashka = prev.babashka.override {
    clojureToolsBabashka =
      let
        version = "1.12.4.1597";
      in
      prev.babashka.clojure-tools.overrideAttrs (_: {
        inherit version;
        src = prev.fetchurl {
          url = "";
          hash = "sha256-DgEvXVExaexDTLoonh/fVS5nHjgekL6BlFYLM9X6wkM=";
        };
      });
  }
}

@seancorfield I feel a sudden urge to defend nix, or clarify 🙂 Nix itself isn't a package manager - it's a packaging tool that we find very useful for defining reproducible dev environments in a fairly polyglot and multi-platform work environment - and you can package whatever you like. Nixpkgs IS a repository of pre-rolled nix packages, and I tend to lazily lean on it until I can't, as I dislike writing nix packages -- mostly because I don't do it often enough to have internalised the syntax. I have a similar relationship with emacs lisp (well, except that I have a subjective aversion to nix syntax -- the guix syntax looks much nicer, but the ecosystem doesn't seem to be as strong).

But you probably know all that already.

Apart from the bits about my own subjective preferences 🙂

My main objection is that these various repos and tools are not "official" as Clojure resources, often lag behind the official releases of Clojure tooling, and also quite commonly do weird things to "build from source" (which the Linux packaging crowd seem obsessed with). For example, a packaged version of the Clojure CLI omitted the tools.edn file so clojure -Ttools ... didn't work. And then time gets wasted helping the poor user debug the problem -- until folks finally go "Oh, wait, did you use the official installer or some random package/repo system??"

(and now your PR against nixpkgs is outdated because 1.12.217 is available... so nix is now three versions behind)

that's how package managers work 🤷‍♂️ all have this error, brew, pac etc, I'd say nix is usually pretty updated, and all the advantages that bring it's totally worth it IMO

currently you can't merge tasks files. maybe something like this will help https://github.com/babashka/babashka/discussions/1044#discussioncomment-11274463

the main issue is that tasks can be written with the current directory in mind. merging tasks from other directories are kind of ambigious with what to do with the current directory

I take a programmatic approach to configuration management. My bb.edn is generated dynamically (see https://github.com/amiorin/big-config/blob/main/.big-config/src/render.cljhttps://github.com/amiorin/big-config/blob/main/.big-config/src/render.clj)), and I apply the same dynamic generation logic to my https://github.com/amiorin/dotfiles-v3/blob/main/src/dotfiles.clj using Clojure.

Usually once a month

but if you desperately need a new release, I can make one

If you don't mind, that would be very helpful at work, so I can move forward with some more script conversions to bb (including the pending tools.deps.edn stuff at work). It all seems to work locally with the latest snapshot but I can't merge that for CI until there's a new stable master release.

sure, will do

done

Update to 1.2.217 locally and confirmed working! Pushing that into CI for a full test 🙂