@svanderburg

@SuperSandro2000

Thanks @Scriptkiddi.

This should not have been necessary -- there was already a new Disnix released (version 0.10) not long before the Nixpkgs 20.09 release.

Furthermore, the issue with rootPassword in the Dysnomia module was fixed as well -- it is now no longer exposed. As a matter of fact, it no longer uses username/password authentication anywhere anymore.

The only reason that I respond to this issue now is because it was buried very deeply in my mailbox, in which I have thousands of notifications emails. This one probably slipped through, but the issue was addressed nonetheless.

While I could easily revert this merge request and restore the functionality, I have not done this yet for a different reason -- I have my doubts whether these modules should come back into Nixpkgs/NixOS. Ideally, I want to manage them outside Nixpkgs/NixOS, but unfortunately, there is no easy way to do that yet, until Nix flakes become more mature and an accepted solution.

Maybe I still restore the packages -- you only need the Disnix service to make it run in multi-user mode and/or to expose the properties of services deployed in a NixOS configuration as Dysnomia containers (deployment targets for Disnix). Disnix/Dysnomia can still be used in single-user mode and for systems that don't rely on parts that are provided by NixOS.

Unfortunately, I know people who still rely on the availability of these modules, so for the time being, I may have no other choice, but to restore them.

Hi @svanderburg thanks for replying. There has been a few occasions that I have tried to get in touch with you over a period of months. It seems like github notifications aren't the right way. Certainly I don't want to monopolize your time, but in the future if there is important nixpkgs business that someone wants to get in touch with you, what would the best method of communication be?

Adding another voice to the discussion:

There is a wider issue of the status of the disnix ecosystem. It's been with Nix for over a decade as a production system for a few people, and also available to the general public as a project in an experimental status. Nix itself is often a barrier to entry, and Disnix only raises that bar higher. [I've used it to quickly develop and meet production needs under tight schedules for short-term projects, but have not been garner adoption for it or Nix into general usage for long-term deployments]. Nevertheless, having a Nix based service orchestration system available is valuable part of the design space to explore. There should be a wider discussion, perhaps moved to Discourse, about this.

I believe this removal was a premature. Marking it broken or disabled rather than a complete purge would have been more appropriate. I regularly review PRs and I either must have missed this or neglected to comment beforehand.

To move forward:

• Identify what issues should be resolved to restore Disnix/Dysnomia.
• Describe what is needed to make the Disnix ecosystem a first-class citizen in Nixpkgs. (or can this be done with flakes?)
• Start community-wide discussion if there should be a coordinated effort to support Disnix.

@tomberek I don't understand how 455 days is premature. It appears there is a communication breakdown between @svanderburg and nixpkgs which I hope we can address in a productive way.

On the topic of being productive I appreciate your "To move forward:" points and agree that what you said is a very good way to move forward. Thanks for suggesting this.

@aanderse Typically raising issues in the corresponding repositories (e.g. Dysnomia and Disnix) is much more effective for me than searching in the already huge list of Nixpkgs issues. This is much easier to see and filter for. I regularly check, but for example after a period of inactivity (e.g. a holiday) it is really difficult to catch up again.

I guess I missed this issue completely, because at the time it was raised (e.g. over 450 days ago), I was probably away from my keyboard for somewhat long period of time.

@tomberek I think this issue is not specific to Disnix alone and maybe requires a broader discussion in the future. For example, with Hydra, we have a similar problem. Furthermore, the Hydra NixOS module was also originally managed outside the Nixpkgs repository, but was eventually added to Nixpkgs/NixOS because there was no convenient way to refer to NixOS modules that reside elsewhere.

I believe (when the time is right), Nix flakes will be the way forward so that Nixpkgs/NixOS no longer becomes a gigantic repository that has so many packages in it that all should follow the same release cycle.

Anyway, l'll make sure that the functionality gets restored. This should not be too much of a problem.

Hopefully, we can still keep the mutable systemd directory option included. For other reasons than the fact that some tools use it, I also believe it is a useful feature -- maybe we can "productize" it by mentioning it in the Nixpkgs/NixOS manual, instead of removing it. For me personally, it also a good development/debugging feature. Removing it requires you to always deploy a new NixOS confguration or package in the system profile.

Thanks for the point of contact @svanderburg!