Project status / maintenance update?

[oneingan]

Hi divnix/std maintainers,

I wanted to ask about the current maintenance status / roadmap. Activity in the repo has seemed a bit quieter lately (e.g. last code push appears to be around 2025-08, with a number of open issues still pending), so I'm not sure what to expect in terms of ongoing support.

Thanks!

[whs-dot-hk]

I don't use std now; but I am still using hive daily

[oneingan]

I went in the opposite direction, I moved away from Hive to Clan Machines (and I'm even considering developing a custom Clan block type) while I still rely on std for my SLDC workflows, covering everything from development through to chart deployment. The CI auto-discovery feature has been working great for me too.

I also recently started experimenting with agentic development workflows, and I've found that giving agents the instruction to "run std to see what's available in this repo" is a total game changer. It gives them instant context about the codebase

[Mayeu]

Based on a true story (that may be in prod right now):

[sshine]

The response I got when contributing to divnix/nix-book a couple of years ago is that at least @jonringer's efforts were aimed at https://github.com/ekala-project/ which I've heard him still mention as late as the last Nix Freaks #17 podcast episode (implicitly in the context of a nixpkgs fork).

[jonringer]

yea, unfortunately blaggacao and nrdxp have stepped away from FOSS for the short term.

[Mayeu]

So I have started to merge the changes I needed (and do some dependencies upgrades/fix), in my own forks:

• https://github.com/Mayeu/std
• https://github.com/Mayeu/std-action

I want to stress out that I'm far to understand the whole subtleties of the code, but I needed to have some updates/fixes/PRs merged to continue using std simply.

[blaggacao]

Would it help to grant maintenance to someone willing and interested to evolve this project?

In my current mind, the best long term strategy would be to converge towards devenv - which aready has a pretty nice UX.

I've got word that plans for NixOS support is part of the roadmap.

I bet, that if people having gotten used to the scenarios and workflows covered by std merge efforts with devenv development, then mid-term, all would be served.

In that context, I especially want to highlight Domen's curating capability due to his long-standing Nix experience and the vision of devenv to provide a polished UX in all aspects that matter most.

[gabyx]

I like devenv, the only thing which worries me a bit is that I am not sure if there is enough effort to upstream certain changes to Nix and what happens when it becomes enshittyfied with all AI and where the payment model is going to be, CI only or on caching etc etc....

Currently we use normal flakes, flake-parts which gives good structure and easiness togeteher with devenv lib to create shells... We rely currently mostly on nix build "<installable>" or nix develop "<...>" in all our tooling.
cause I think those are much stabler and closer to the community. Eventough the nix develop is of course by far more troublesome, less feature then what devenv provides...

[Mayeu]

Would it help to grant maintenance to someone willing and interested to evolve this project?

I think it will yes, do you have some people in mind?

In my current mind, the best long term strategy would be to converge towards devenv - which aready has a pretty nice UX.

Interesting, I didn't look at devenv for a while and it grew a lot!

[blaggacao]

I think it will yes, do you have some people in mind?

No. Interested parties please reach out on matrix 👍

[nrdxp]

Just to chime in here; I personally cannot speak toward devenv at all, as I haven't used it, but I would expect it to be far better maintained at this point.

As for std, I am definitely on board with delegating maintainer access if anyone is interested in upkeep. Also happy to assist with any knowledge transfer in such an event. I just don't have much bandwidth to focus here atm, unfortunately.

[oneingan]

I’m surprised to see devenv proposed as a migration path for std.

To me, std and devenv solve different problems. devenv seems great for environments, services, tasks, tests and containers, but std’s distinctive value is the Cell / Cell Block / Target / Action model, the #__std registry, selectors, and CI/discovery story.

Maybe devenv has grown beyond what I remember, but I don’t yet see it as a drop-in conceptual replacement. I’d love to understand what the intended migration would look like: flake-parts + devenv, devenv modules inspired by std, or an actual replacement for the registry/artifact model?

[blaggacao]

It might not be there yet, but given that maintenance of std has effectively stopped, it's hard to imagine a viable long time path forward towards better integration or more polished workflows.

My guess is that if some of the use cases are brought into the devenv effort as user requirements, there may be a long term viable path to better intergation and polished workflows.