14 results
42:54
10Pierron, Nicolas B.For many reasons, Nixpkgs cannot accept every package ever created. Things have to change, let's make sure we can at least include every package, even if they are not part of our central repository! Since December 25th 2016, we are now able to use Overlays. Overlays gives us the ability to change the way Nixpkgs see the world, while providing most of the benefits that we can get from it. This presentation will address the following questions: Why overlays are useful, across a community, across an organization, or across the world? How to write an overlay with a few good and bad examples, and digging in the internals of Nixpkgs to understand how overlays are working? What can we do to improve the usage of overlay even more? What parts of Nixpkgs should be converted into overlays?
2017NixCon
34:19
5Christensen, GrahamNixOS is receiving more and more attention from users expecting up to date packages and timely security patches. Weekly "catch-up" issues were effective, but faltered after our datasource dried up. In this talk we will explore the challenges and potential solutions around regular NixOS security patching, and how to join the famous "-distro" list.
2017NixCon
18:03
7Christensen, GrahamInfrastructure automation testing is hard, but NixOS makes it a breeze. Using NixOS' testing framework, Tumblr developed a comprehensive integration test suite for Jetpants, Tumblr's database automation toolkit designed to manage billions of rows and hundreds of database machines. In this talk we will explore the challenges of testing Jetpants, mimicking complex replication and sharding topologies, and future applications of NixOS at Tumblr.
2017NixCon
46:38
15Peebles, DanielFor the past couple of years, Darwin has been a first-class "pure" platform on Nix. In this talk I'll describe the many hurdles we've had to overcome to get from an impure poorly supported platform to where we are today. I'll also cover ongoing pain points and where we see the platform going, and why I think it should take over the Mac packaging ecosystem. When I first encountered Nix, I was simultaneously impressed by the purity of its Linux environment with virtually no untracked external dependencies, and disappointed with the situation on macOS. On macOS, some of my first experiences with Nix involved some painful surprises of impurities breaking my Nix builds, and my early attempts to fix them largely failed. As I tinkered with Nix and spoke to experts online, a clearer picture emerged for how to move from the impure situation to a pure one, and a few of us banded together on IRC over the following few months to bootstrap a pure compiler toolchain and OS-appropriate SDK from scratch. It's a grueling story of mass rebuilds multiple times a day, repeatedly waiting for three hours just to find stupid typos, and hunting down undesired dependency chains, but in the end it came together and actually worked, much to everyone's surprise. Although the situation is now far better than it was, there is still much work to do, and I'll go over some of the root causes of much of the remaining pain and how I propose to tackle it. I'll also go over some exciting recent developments in the macOS Nix space and what I think the project and platform will look like in the longer term.
2017NixCon
27:57
36Dijk, Bas vanLumiGuide develops and maintains bicycle and car parking guidance systems that are deployed in various cities in the Netherlands and abroad. To run this system a number of different machines are needed: image analysis servers deployed locally in facilities, central web-servers and support servers in data centers, embedded machines like Raspberry Pi's and ARM FPGA's to power our various displays in facilities and on the streets. Finally our engineers have workstation to write our software. All these machines need to be developed, tested, provisioned, configured, installed and rolled back (in case we make a mistake). Since we don't have a dedicated sys-admin we rely on automation to do most of these tasks. We use the Nix ecosystem of tools to help us with that. I will talk about how we've structured our mono-repository, how we make sure each engineer uses the exact same version of nixpkgs and the exact same NixOS configuration, how we override our Haskell packages, how we use Continuous Integration wit hydra and how we deploy our machines using nixops. Finally I will also talk about the things that we don't like about the Nix ecosystem.
2017NixCon
29:41
1Dolstra, EelcoIn this talk I will give an overview of the new features in Nix 1.12, and the ongoing work on the "nix" command intended to replace the existing command-line interface.
2017NixCon
27:40
8Jordan, SebastianThis talk wants to give an overview over the usage and development of pypi2nix, a tool to generate and maintain python environments with nix. pypi2nix is already a viable tool to generate and manage python environments with their respective dependencies inside of nix. The first part of this talk will be focused on the current functionality of it. This includes features and shortcomings. The second part of the talk is about nixpkgs-python and how we use pypi2nix to maintain semi-automated self-updating sets of python packages. Finally we will discuss how pypi2nix could be used to maintain python package sets inside of nixpkgs in the future.
2017NixCon
41:09
2Maudoux, Guillaume (layus)The current CI infrastructure around nixpkgs has difficulties to build the whole package set in due time. While there were attempts to build every pull requests, these are not enabled by default because it requires even more resources. We will explore how to optimize even more the build process to meet the size of nixpkgs. We will survey with state-of-the-art build systems like scons, bazel and tup to see how we could improve incremental builds in nix. Based on nix-make, we will describe how nix could cooperate with the build tool of a given package to bring incremental builds at a finer granularity. In particular, we will explore how the intensional store model (as used by bazel for example) could help avoiding some mass rebuilds.
2017NixCon
39:22
8Hufschmitt, ThéophaneWe present here the new tix tool, a type-checker for the Nix language whose goal is to make nix code easier to write and maintain. Nix's strength comes from the ideas it borrows from functional programming: immutability, powerful abstraction capabilities, etc.., yet it misses one of the most emblematic and powerful feature of most functional programming languages: a strong static type-system, which becomes a problem given the increasing size of the Nix package collection. This proposal (which is the result of an internship funded by the Nix community and tweag I/O and supervised by Guiseppe Castagna) tries to fix this. The resulting type-system and typechecker have been designed with two very important constraints in mind: The type-system must be able to offer as much safety as possible for the programmer. One must be able to reuse existing nix code with as few modifications as possible. This means that: Most of Nix idioms have to be supported by the type-system − in particular the presence of types at runtime and the dynamic fields in the records, There must be ways to bypass − up to some extent − the type-system, using e.g. gradual typing or by locally disabling certain errors. In this talk, we will present the tool from the practical point of view of the nix user and discuss further improvements.
2017NixCon
42:21
14Kožar, DomenTalk with go through lessons learned using Nix in last two years to automate software distribution. What are the common technical and process obstacles using Nix to ship software in production - mean that customers depend on the pipeline. What supportive tools and Nix features were used, what Nix features aren't useful, where do I see improvements are needed. What do I see as something that will boost Nix usage in companies and what's my plan to get there.
2017NixCon
36:32
4ProfpatschWhile there is pretty good support for testing NixOS based services inside VMs, the same doesn’t hold for large parts of nixpkgs, especially for testing packages. I will present different approaches to improve testing. Over the last year I have been creating various testing environments, tried out different approaches and created tests for various parts of nixpkgs, notably package tests with very interesting properties. There are two kinds of tests in nixpkgs right now: /lib/tests: this is essentially a derivation that tests (some/most) library functions by checking their outputs. /nixos/tests: contains a list of tests for modules that use the VM testing infrastructure (`/nixos/tests/make-test.nix`). Both kinds of tests live in a different part of the codebase than the implementations they test, and have to be run separately, and manually (by hand or by CI). This leads to easy desynchronization of test- and actual implementation—the tests bit-rot over time. I therefore propose two maxims: All testing code should be as close to the implementation code as possible. Changing the implementation should not be possible without adjusting the testing code to make it pass. Coming from this angle, I recognized that a unique property of nix evaluation—short runtime—makes it possible to let nix packages depend on their tests. This is accomplished by a `seq` for derivations, discovered with @aszlig. I will present how drvSeq makes it possible to create package tests that are able to use the full power of the nix language for abstraction. It also does not cause unnecessary recompilation, like changing the checkPhase does right now. Going further, I will discuss best practices for including these tests into already existing packages. As well as packages, functions (and thereby whole language frameworks) can be tested as well, enabling a kind of testing that is automatically done to every usage of the function (i.e. every package in the framework). This could lead to interesting use cases. While VM tests already work with automatic CI support, their code location is not satisfying according to maxim 1. I will propose an integrations of VM tests as a module option, producing outputs neatly piecing into the current hydra setup.
2017NixCon
32:15
7Chevalier, Jonas (zimbatm)This talk explores ways to introduce Nix into an existing infrastructure (at work), based on real-life experience.
2017NixCon
45:47
1Pletz, Franz (fpletz) et al.As the latest release managers, we will describe how NixOS releases have been done in the past and how we want to encourage the Nix community to participate in the release process. We are going to highlight some interesting new features of past releases and the then brand-new 17.09 'Hummingbird' release. Finally, we present you some ideas for features we would love to see implemented. We will give you an impression of the NixOS release process, how the release team works (RFC15) and your duties as release manager. Not to scare you away but to motivate you to step up as the next release manager. In particular, we will give you an overview of promising features the community has suggested but remain to be implemented. Some of those are general service hardening with systemd, a new test-runner container backend for quicker service tests and the service abstraction layer to use NixOS service modules in Docker containers or swap init systems.
2017NixCon
13:43
5Strobel, ThomasNix User Profile (NixUP) should have been a declarative configuration for the user environment [1]. By now similar solutions have emerged, like nix-home [2] or home-manager [3]. In this talk the different approaches will be reviewed and an update on the state and future of NixUP will be given. [1] https://github.com/NixOS/nixpkgs/pull/9250 [2] https://github.com/sheenobu/nix-home [3] https://github.com/rycee/home-manager
2017NixCon