Survey: Preparing Holonix for Holochain RSM

Hey everyone,

I’m interested in learning your usage patterns of the commands provided by Holonix as I’m about to make Holonix ready for Holochain RSM :slight_smile:

On the way I’d like to take the opportunity to generally clean out the Holonix and add improvemts to the workflow if I can.

General questions

  1. How do you launch Holonix and for which type of development (HC Coredev, hApp Dev?) do you use it?
  2. Which of the hc- and hn- commands do you use, and how often?
  3. Are any of these commands behaving unintuitively, and do you have any suggestions or wishes for improvements to it?
  4. Are there any common workflows part of your development process that could be simplified by adding new or combining existing commands?

I’m sure the above list of questions doesn’t cover all potential feedback. Please don’t feel limited by the list and share anything that is on your mind about Holonix and how you think we could improve it! I’m looking forward to receiving lots of feedback so that you can all benefit from the upcoming Holonix update!

Cheers!
Stefan

In the acorn project we have been using holonix, and the main hn- command we use is hn-release-github

The only funny thing about it is that I don’t understand its behavior relating to the changelog. For that reason we don’t use the changleog, but I’d like to.

See https://github.com/h-be/acorn-hc README to see mention of our release commands which use that.

Hi @steveeJ, glad this is moving forward.

To be honest, as a happ-dev the only part that I use of holonix is to manage the dependencies for each of the projects - as in, you specify a default.nix in each repository and you forget to manage multiple holochain installations and so on. In this way, it really shines. I can’t stress enough how much I want this to land to avoid the majority of issues on the RSM environment setup in all the projects I’m in touch with.

But apart from that I don’t really use it at all - and I think that’s because ignorance about Nix itself, lack of familiarity and understanding of it, and of documentation about holonix. I’m mostly surfacing this because I think this is the case for almost all happ-devs I know, I think I only know of Connor and Pospi (I think), who use it quite extensively. Of course, I’m willing to change that and learn.

The few times I’ve played the role of a core-dev, it has been indeed very handy. I’ve mainly used hc-install & hc-doctor, as well as hc-merge-test and hn-rust-fmt-check.

2 Likes

So far I use Holonix as a way of making sure I’ve got all the stuff I need, and that it’s in a state that’s consistent enough that nothing gets broken. (For me, when I run tests against the HC dev docs, it’s nice to know I’m running them against, e.g., HC-Redux v0.0.52-alpha2 or whatever.)

The tools I used most were these hc subcommands:

  • hc init
  • hc generate
  • hc package
  • hc run

This was mostly while walking through the tutorials to make sure they still worked. @guillemcordoba and company are planning on building a ‘Holochain Gym’ which I hope will replace the tutorials; maybe it’d be good to look at what would support new hApp devs as they walk through the gym!

I think scaffolding tools would still be lovely; I find it tedious to bootstrap a DNA and zome project, and I think new devs would be lost without it. However, I feel like some work could be done to make it both more generic and more versatile – more generic in the sense that the currently generated templates had a lot of unnecessary code that you’d always have to delete (they were attempting to scaffold and give a mini-tutorial); more versatile in the sense that they ought to let you specify the needed zomes, entry types, and public functions like Lisa and Robbie’s hc-happ-scaffold did. (I’d like to see an all-command-line scaffolding tool that doesn’t necessary require a schema file – kind of like the one in Ruby on Rails!)

Thanks for the answers. If you’re interested in tracking the changes we’re making towards the new Holonix release please take a look at CHANGELOG-UNRELEASED.

Because of the different nature of Holochain RSM, many of the tools and commands have been removed, most notably the hc command.

Pre-release you can use the command shown in the changelog to spawn the shell. On Linux, this will also make use of Holo’s Hydra (Nix binary cache). For your convenience and to increase the chances of you trying it out and providing feedback, I’m pasting the command in here as well:

$(nix-build https://nightly.holochain.love --no-link -A pkgs.holonix)/bin/holonix

Looking forward to receiving any feedback :slight_smile:

Cheers
Stefan

2 Likes

But don’t worry about losing hc… the hc commands in Nix have been replaced with ones built into Holochain now.

They haven’t been merged in yet, but are in this Pull Request and you can watch this video demo to see how they’ll work now.

1 Like

I’m getting this error on kubuntu 20.04:

...
warning: the group 'nixbld' specified in 'build-users-group' does not exist
these paths will be fetched (11.62 MiB download, 55.36 MiB unpacked):
  /nix/store/ifayp0kvijq0n4x0bv51iqrb0yzyz77g-perl-5.32.0
  /nix/store/jdi4wl7fc4vp6kjwwyvs3kks5psgns3q-perl-5.32.0-man
copying path '/nix/store/jdi4wl7fc4vp6kjwwyvs3kks5psgns3q-perl-5.32.0-man' from 'https://cache.nixos.org'...
copying path '/nix/store/ifayp0kvijq0n4x0bv51iqrb0yzyz77g-perl-5.32.0' from 'https://cache.nixos.org'...
warning: the group 'nixbld' specified in 'build-users-group' does not exist
warning: the group 'nixbld' specified in 'build-users-group' does not exist
warning: the group 'nixbld' specified in 'build-users-group' does not exist
these derivations will be built:
  /nix/store/0snkkva88nmdhlmc58fc9c5rk3q6gs85-hn-rust-manifest-install.drv
error: the group 'nixbld' specified in 'build-users-group' does not exist
lvvjj549x36xs83p8s4x52z7b6w58l-python-2.7.18.drv
/home/guillem/.holonix/allrefs
Processing /nix/store/0snkkva88nmdhlmc58fc9c5rk3q6gs85-hn-rust-manifest-install.drv

I tried doing nix-collect-garbage but with no luck.

I’m so excited this is getting ready :smiley:

@guillemcordoba see the ubuntu dockerbox for an example of fixing this - https://github.com/holochain/holonix/blob/develop/docker/Dockerfile.ubuntu#L18

1 Like

Thanks @thedavidmeister !! It’s working now ^^

Omg this is so cool!! Thanks @steveeJ! Is this updated periodically? Or not yet?

The event chain for updating the revisions is manual for now. Holonix now relies on the Holochain packages in the holo-nixpkgs repository which provides a binary cache and is subject to integration tests.

I can see us setting up automated version bumps in the mid-term future after we’ve set out a plan for official Holochain RSM releases.

1 Like

@steveeJ okey thanks! Another relevant question for us happDevs. Will the strategy of having a default.nix in our repository to lock the holochain version we are using continue? This is what we did in redux, and it was very useful to work across projects and maintain sanity with our local environment. If that’s the case, can a sample default.nix be used right now for this purpose?

Hey @guillemcordoba. As discussed out of band, nothing should have changed in that regard. Instead of a version you can use the branch name love or go to the repository and pick a revision manually, and put that in your config.nix (don’t forget to modify the sha256 to invalidate the cache).

1 Like