2023-05-04 - Learning Journey Working Group - Meeting Notes #7

2023-05-04 - Learning Journey Working Group - Meeting Notes #7

Notes

  • @zmitchell: Try to fill the front of our idea to work backwards from a goal

  • @khaled: tested NixOS VM tests on Apple silicon

    • seems to run, but really slow, probably due to emulation
    • may be missing something though
    • @zmitchell: should be okay, good enough as long as it works correctly
  • continuing the outline:

    • packaging an application
      • declaring a derivation
      • specifying Python dependencies in Nix
    • setting up a development environment
      • creating a shell.nix
        • Nix language basics
        • Dev tooling, linter, language server
      • @fricklerhandwerk: What’s a dev environment speficically? Text editor, Git config etc. included? Only build environment?
        • @zmitchell: No text editor, etc.
        • @fricklerhandwerk: Configuring Vim declaratively is one of Nix’s killer features, could set it up in Home Manager
          • does not have to be a mandatory on the path towards NixOS tests
        • @zmitchell: E.g. Python 3 should be included, can play with the interpreter, linters should be included as well. Tools for development should be around.
        • @fricklerhandwerk: Should break it down, eventually should cover project-independent configuration as well
        • @brianmcgee: There’s two types of people: Hard-core terminal users and the rest
        • @fricklerhandwerk: Graphical interfaces often don’t work that well in Nix, terminal programs however do.
        • If we include Home Manager it also (once again) raises the question of what’s an official project.
          • Should we maintain something we don’t own?
          • Also consider relative importance of those use cases are for new users
      • @khaled: Often needs an IDE that can see the Nix environment for tooling, some extensions, maybe link to some VS code extensions that help with integration
        • @brianmcgee: usually launch the IDE from a Nix shell so it has the same environment, otherwise it’s problematic
          • have to consider best practices
        • @fricklerhandwerk: Hints at needing a good editor setup. We should assume there’s Nix available, can start out with just vanilla Nix, but later introduce home-manager. Start out with a simple home.nix, fairly easy to configure, only get into packaging Nix expressions later
        • @zmitchell: have to consider that not all users are on Linux
          • home-manager is cross-platform.
        • @zmitchell: Feels like we include too many things from the start.
          • @fricklerhandwerk: that’s true, but what are the alternatives?
            • can’t jump into seemingly simple things that have non-obvious prerequisites
          • @asymmetric: Agree, how far can we get without home-manager? shell.nix, direnv optional as an extra bit, not required. Better to do it the basic way before introducing shiny things.
          • @khaled: Agree that we shouldn’t talk about home-manager at the start. It’s also orthogonal. Can link to extensions.
            • @fricklerhandwerk: We need to ensure we have all prerequisites for tutorials. Proposal: Have a golden path that definitely works, leave pointers to alternatives. New people will be overwhelmed when needing to solve problems that arise when following tutorials
              • Home Manager with Vim and direnv is such an example, but we can come up with something that just works and possibly covers a larger fraction of the target audience (e.g. VSCode) or has a smaller set of prerequisites
              • Long chain of prerequisites is not a show stopper. Some things take time to learn. We may find better ways, shorter paths, when the project matures. Leaping over essential steps is what will get us in trouble though.
        • @brianmcgee: People should understand what Nix is doing: Providing an environment with variables set. So let’s teach early that nix-shell does that, users can run editors and tooling inside this environment then
        • @zmitchell: Isn’t Nix supposed to create a hermetic environment? Why does that work?
          • @brianmcgee: Just layers other environment variables on top
          • @infinisil: Hermeticity only applies to evaluation and builds, not shells
        • @zmitchell: If you use a different shell from bash, on first glance it looks like you enter a new environment
      • @asymmetric: Could have an editor in the environment, like nano, and use that in the tutorials. Should be simple, cuts down on complexity.
        • @zmitchell: How much editing is actually needed for the Python code?
        • @zmitchell: Can get away without having an editor integration for Nix, but not as much for Python. Don’t need to touch on editor setup very much when we don’t need to change much Python.
          • @fricklerhandwerk: the question we should ask ourselves is what gets new users furthest in the shortest amount of time.
            • NixOS tests are impressive, but they are a very sophisticated use case.
            • One could argue that declarative configs will stick around and provide value for long time
              • Git, direnv, editors, …
              • What’s the underlying set skills?
        • @infinisil: Agree to have nano, simple way to ensure people know how to edit files, can use nix-shell -p nano, shouldn’t be in the shell.nix
          • Regarding vim, not everybody uses vim
      • Need to teach pinning Nixpkgs
        • @infinisil: niv? But third-party. Haven’t decided yet
        • @brianmcgee: Could do nixpkgs ? fetchTarball (... rev)
        • @infinisil: First do it just with the hash instead of the branch, then niv sounds good
        • @brianmcgee: I just use Flakes
        • @infinisil: Problem: niv isn’t official
        • @zmitchell: Maybe just start with a fetchTarball with a revision.
        • @brianmcgee: Also more similar to how Nixpkgs works
        • @zmitchell: Can ensure it points to the same revision as in the tutorial
          • Nixpkgs is platform specific, needs to be tested
        • @asymmetric: Probably shouldn’t use niv. Either the inconvenient hash or just master.
          • @fricklerhandwerk: master won’t fly, things will break
            • we talked some days ago about taking a release branch as a compromise, as we can expect it not to change too much
  • Next steps: Sequence the parts and split them into manageable chunks, write down what other documentation should exist, like editor setup, pinning nixpkgs in an ergonomic way, etc. Good for contributors.


@fricklerhandwerk: Here’s a possible skill/knowledge dependency graph

flowchart
  lang[Nix language] --> shell[shell.nix] & drv[declaring derivations]
  drv --> python[Python packaging]
  pinning[pinning Nixpkgs]
  lang --> modules[module system]
  modules --> config[declarative configurations]
  shell & config --> devenv[development environments]
  config & testing[NixOS testing framework] --> vmTests[NixOS VM tests]
  pinning & lang --> reproducible[reproducible builds]
  
1 Like