2023-04-27 - Learning Journey Working Group - Meeting Notes #6

Development Documentation
1

2023-04-27 - Learning Journey Working Group - Meeting Notes #6

Agenda

  • Previous action items
  • New meeting time
  • Pick up where we left off last time
    • Identified most of what we want the end goal to look like

Action items from last time

New meeting time

Learning Journey Design

  • last time: NixOS tests with multiple machines and multiple processes interacting

    • database (Postgres), proxy or webserver (Nginx), web application (Python)
    • while hard to pull off, chosen intentionally to force going through all the preliminaries
    • @khaled is investigating if this will work cross-platform

  • next steps:

    • divide into pieces, with learning goals for each piece

  • find touch points with Nix:

    • NixOS VM tests
      • NixOS configuration
        • NixOS module system
          • Nix language
      • NixOS options search
      • test scripting interface (Python)
      • interactively running tests
      • packaging an application
        • declaring a derivation
        • specifying Python dependencies in Nix

  • @infinisil: should not go too deeply into incremental developer environments, that’s not something Nix can do itself

    • @fricklerhandwerk: agree, at the worst all of the results will be completely invisible, and that’s okay since we want to teach Nix-specific concepts and techniques
    • @zmitchell: Disagree, it’s important to be able to test things manually without having to create VM tests.
      • Should have a script that we can just call and have it run the server
      • @fricklerhandwerk: Both are important, incremental development and CI

  • @fricklerhandwerk: Let’s try to cover one component skill, e.g. Python packaging. Not sure if there’s even a recommended way

    • @zmitchell: Working with Nix from the ground up → just use pythonPackages
      • @infinisil: Has some problems, needs manual updates, but it’s official so I’d say we should go for that
    • @fricklerhandwerk: Wouldn’t recommend the Nixpkgs way, gets you stuck very quickly.
      • Minimum for a Python package is a requirements.txt file, not supported by Nixpkgs AFAIK
    • @asymmetric: How about poetry2nix
    • @zmitchell: Python has various package managers and dependency resolvers, just using Nix doesn’t require a specific package manager.
    • @infinisil: poetry2nix seems pretty good
      • @asymmetric: have to provide some information, since it does a few things that may seem unusual to Python natives
    • @fricklerhandwerk: We only need to pick one way to demonstrate the principle
    • @infinisil: How about leading from pythonPackages to poetry2nix to show the diversity of tooling
    • @fricklerhandwerk: Wouldn’t recommend, alternatives add mental overhead, less variants is better, should be our goal
    • @infinisil: But there’s no unique best solution, there’s tradeoffs
    • @asymmetric: Similar to flakes problems: There’s no bridge from non-flakes to flakes, confusing people. Similar to this, showing a path from one tool to another would be helpful for people
    • @fricklerhandwerk: Two aspects:
      • A different tool can solve different problems, the tool itself should demonstrate that
      • People should be able to use it immediately, nobody uses pythonPackages to build applications
        • @infinisil: They do, it’s not that problematic!
    • @zmitchell: pythonPackages is important to show. If people run into problems, other tools can be used.
      • @infinisil: Upstreaming also requires knowing about pythonPackages
    • @fricklerhandwerk: pythonPackages just happens to be an integral part of Nixpkgs, it’s not a great solution. While working with pythonPackages could teach some things people need, it’s just not scalable for practical work.
      • Most importantly it’s not backwards compatible with the rest of the world using requirements.nix or pyproject.toml
    • @infinisil: Scalable to Nixpkgs, also how all Nixpkgs packages are done
    • @asymmetric: Decision to stick to stable interfaces should be upheld. Could allow people to select different ways of doing things.
    • @zmitchell: Agreed, show the official way but link to other ways of doing it.
    • @henrik-ch: Important to keep the tutorials straightforward. We could support the official version on nix.dev and assist or contribute to external projects in order to improve their documentation
      • That is of course a resource problem
      • @zmitchell: We should be the ones who maintain the material we write, this probably won’t work for third-party projects
        • More general question: where should the best practices be documented?
    • @infinisil: How about looking at third-party projects, seeing which aren’t superseded by others, look at tradeoffs/advantages/disadvantages and list these on nix.dev
      • @fricklerhandwerk: This woudl be another rabbit hole that we’d have to go into. Should rather focus on teaching skills that can be reused in different contexts
    • @infinisil: Why not use show both poetry2nix and pythonPackages, they have different use cases, both valid

  • Ran out of time before reaching a consensus on poetry2nix vs pythonPackages.

Action items

3 Likes