- Previous meeting notes
- Attendees: @zmitchell @khaled @henrik-ch @Jeremiah @06kellyjac
- Notes taken by: @henrik-ch
- @06kellyjac introduces themselves.
@zmitchell a question was asked on the discourse what was the purpose and what was supposed to be learned from the nix documentation efforts - i.e. what are the learning goals that should be achieved
- we want to have this as a living document
- we might return to this point (keeping track of these learning goals)
@zmitchell - we want to chunk and sequence the nix learning journey
- we’re going through previous meeting notes to get to the point we arrived to in last meeting
- dependencies should be the next piece of learning introduced
- getting flask and something in addition
- add these to your environment
- build inputs?
- it’s important to consider python path in this context
- if we only use flask add it to build inputs
- if you need more than that, it gets trickier - because also needed on python path - hence need for buildpythonapplication
- previous step shell.nix - we spoke about buildpython application or not for this step
- at some point, we will need to address this topic (build python application)
@06kellyjac python has a special property/feature - withenv command?
- pyEnv = pkgs.python.withPackages(ps: [ ps.mininet-python ]);
- (someone mentions poetry2nix)
- @zmitchell we’re sticking to nixpkgs, to try to stay away from third party tools - as we are becoming a more formal documentation source - and less opinionated.
- @zmitchell they might bring an already existing py project - and that will influence the way that they choose to build it - i.e. if they were already using poetry, pip, or pipenv
- coverage in nixpkgs - things that have been installed outside - might still be - @06kellyjac this is something to warn against - so that you don’t believe that you have a working insulated solution - when you actually are partly running on the global system python.
@kellyjac there is an argument for enabling the user to do whatever they need to do.
- @zmitchell - if we need to make such shortcuts, make them as good as possible - global install would be one of the worst options
- @khaled this is sometimes mentioned in the community as “turning off the sandbox”
- @zmitchell - what we’re aiming at is something that doesn’t pick up globally installed packages
@zmitchell needing additional packages to flask, we need to go to buildpythonapplication
- we’re looking at nix example from last meeting
@zmitchell - looking at different build input types
@zmitchell - tell me if this is correct
- propagated build inputs - needed at build and runtime
- build inputs - needed at runtime
- native build inputs - needed at build
- build inputs - needed by built package
- native build inputs - needed at build time
- propagated build inputs - needed by built package and included in output?
- @06kellyjac - need to look at the details how the python path works and with the wrapping
@zmitchell - tricky nix thing we want to teach - there is a difference between these build input types
- @zmitchell - is it for this tutorial?
- @henrik-ch this sounds fairly difficult for a beginner
- @zmitchell - tell me if this is correct
@06kellyjac python situation is one of the more difficult within nix - specific version that you need and pin to
- you may be using requirements.txt - and this feeds into what needs to happen nix wise
- add hooks for testing
- including dependencies - directly from your python.packages - or python.packages.corepackage? so you can get dependencies in arguments???
- easy example - basic c program?
- we can then easier add to the shell - to make the build dependencies included
- @zmitchell - we need to show these rough edges - people say they struggle with the language, but they actually struggle more in general with the ecosystem and how things are set up.
- @zmitchell we intentionally chose python - with its rough edges.
@06kellyjac use a few of these input types as possible - use something with only propagated build inputs?
- @jeremiah - by hiding the difficult side of it, we may do the users a disservice - we should probably mention that they exist at least. After the python learning journey, we can template it and do it for other languages - Rust and others?
- @zmitchell - we want one learning journey
- @zmitchell - as 06kellyjac said, we can introduce the buildinputs one after the other.
- @zmitchell - as a beginner - wanted to create an environment that had specific things at runtime and build time - got a reply that fleshed out with type of inputs should be used where - but it was hard to digest as a beginner.
- @zmitchell - “these are propagated build inputs - you don’t need to know right now - but we will teach you later”
@zmitchell - can we introduce a linter or something similar? - only needed at build time
- @06kellyjac - yes - they will go in native build inputs
- many scenarios exists where you need to know the difference between the inputs - but we will try to avoid that in this tutorial
- buildpythonapplication command will be introduced
- @zmitchell - this sounds like a managable amount of complexity
@Jeremiah - shall it be copy paste, or should a specific repository be set up?
- @Jeremiah - the may be ways to segment the existing repo instead of making a new one
- @Jeremiah - one repo as a collection of all needed assets (to be cloned)
- @zmitchell - dealing with keeping a clean commit history for teaching purposes is unsustainable over time
- @zmitchell - end goal building with testing and nixos - what comes next?
@zmitchell - we need to teach pinning nixpkgs - and for that - you need to understand nixpkgs
- making builds reproducible - and select your architecture
- that will define things all the way down to paths
- this is powerful and should be shown to people
- @Jeremiah - subtutorial - how granular can nix get on pinning - from branches to commit hashes
@zmitchell - discuss and explain different levels of purity
- from channel - say 22.11 - not reproducible - because channel evolves
- pinning to commit hash - maximal granularity
- @zmitchell adding packages or pinning - which one comes first?
@06kellyjac teach pinning as soon as possible - gives better guarantee that things will work
- pinning is relatively simple to understand - in comparison to other python topics
- @zmitchell- pinning - and then adding flask - and get it running
- @zmitchell - next - add derivation?
@zmitchell we will have shell and derivation using build python application - and would essentially be the same
- using mkshell - no flask on your python path - therefore it’s not a good way to go
@khaled showing unified build and shell from @infinisil
- @06kellyjac - two options regarding the flask integration
- @06kellyjac - shall we postpone until @infinisil joins?
- @Jeremiah - store inputs and propagated build inputs?
- @06kellyjac - then we could reuse and wouldn’t need two - transfer logic from shell.nix to default.nix, and make shell.nix depend on default.nix
- @zmitchell - first instance - duplicate what needs to be duplicated - optimise files for readability and understandability - to get something building
- @zmitchell - later tutorial - optimise our nix code to not repeat itself
- @zmitchell - going forward - we need a nix expert in the room to make progress on this - and this will become more the norm going forward as we are onboarding people with these skills