profile
viewpoint
Alyssa Ross alyssais The Internet Berlin https://alyssa.is @NixOS nixpkgs committer, former @Homebrew maintainer. Working on https://spectrum-os.org, a compartmentalized operating system. she/her 736C CDF9 EF51 BD97 Ⓐ

alyssais/auto-ebooks 4

Automatic Twitter ebooks bots.

alyssais/cascading-attribute-sheets 2

Compile HTML using CSS-like selectors to apply attributes.

alyssais/bingnews 1

A Node library for getting news data from Bing

alyssais/brew 1

:beer: The missing package manager for OS X

alyssais/bugwarrior 1

Pull github, bitbucket, and trac issues into taskwarrior

alyssais/bulbatrivia 1

A bot that tweets random trivia from Bulbapedia

alfiepates/bork-boilerplate 0

👩‍🍳🚂 A minimal starting point for configuring your machine with Matthew Lyon's wonderful Bork.

startedNico640/docker-unms

started time in 2 hours

fork MikeMcQuaid/homebrew-xorg

:heavy_multiplication_x: :penguin: X.Org implementation of the X Window System

https://docs.brew.sh/Homebrew-on-Linux

fork in 7 hours

startedtomnomnom/gron

started time in 19 hours

startedPaulAnnekov/tuyaha

started time in 19 hours

startedramsayleung/rspotify

started time in a day

startedzmb3/spotify

started time in 2 days

fork CodaFi/bootstrap-managarm

Patches and build scripts to build a managarm distribution

fork in 3 days

startedruffle-rs/ruffle

started time in 3 days

startedtimhutton/sdl-canvas-wasm

started time in 3 days

fork issyl0/sorbet

A fast, powerful type checker designed for Ruby

https://sorbet.org

fork in 3 days

pull request commentNixOS/rfcs

[RFC 0050] Merge bot for maintainers

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/misuse-of-commit-permissions/10071/38

FRidh

comment created time in 3 days

created repositoryticky/docker-isign

Docker image with macOS/iOS code signing tools

created time in 4 days

startedisignpy/isign

started time in 4 days

startedzhlynn/zsign

started time in 4 days

startedreplicate/replicate

started time in 4 days

startedgleam-lang/gleam

started time in 5 days

pull request commentNixOS/rfcs

[RFC 0042] NixOS settings options

So we had a short meeting on this RFC where everybody but @fpletz was present. To call out the FCP we want the following things to be updated in the RFC:

The following two core ideas in the RFC should stay:

  • Use settings options/free form options instead of extraConfig
  • don't introduce too many options for every possible configuration.

Instead of the proposed implementation it should now link to the nixpkgs manual that describe free form modules.

Infinisil

comment created time in 5 days

startedsnej/nimdbx

started time in 5 days

Pull request review commentNixOS/rfcs

[RFC 0078] System-agnostic configuration file generators

+---

Squashed the edits until now. Seems to have helped.

7c6f434c

comment created time in 5 days

push eventNixOS/rfcs

Tuomas Tynkkynen

commit sha eee65998c1d35c06906d97b45e883a1a33504cb7

[RFC 0032] Phase running changes for better nix-shell use (#32) Co-authored-by: Linus Heckemann <git@sphalerite.org>

view details

push time in 5 days

PR merged NixOS/rfcs

[RFC 0032] Phase running changes for better nix-shell use status: FCP

Making some minor tweaks to how phases are run in the stdenv to improve the UX of nix-shell.

Rendered view: https://github.com/dezgeg/rfcs/blob/phase-changes/rfcs/0032-run-phase-changes-for-better-nix-shell-use.md

+180 -0

36 comments

1 changed file

dezgeg

pr closed time in 5 days

pull request commentNixOS/rfcs

[RFC 0075]: Declarative wrappers

So this RFC has the following shepherd: @FRidh, @lheckemann, @edolstra. Thanks!

doronbehar

comment created time in 5 days

pull request commentNixOS/rfcs

[RFC 0075]: Declarative wrappers

Nominating myself as a shepherd.

doronbehar

comment created time in 5 days

pull request commentNixOS/rfcs

[RFC 0078] System-agnostic configuration file generators

@Profpatsch would you be interested in being a shepherd on this RFC?

Generally this RFC is in need for more shepherds before being able to move onwards.

7c6f434c

comment created time in 5 days

Pull request review commentNixOS/rfcs

[RFC 0078] System-agnostic configuration file generators

+---

For some reason 0072-commonmark-docs.md is part of this RFC, could you remove it?

7c6f434c

comment created time in 5 days

fork mistydemeo/LuaJIT

Mirror of the LuaJIT git repository

http://luajit.org

fork in 6 days

pull request commentNixOS/rfcs

[RFC 0078] System-agnostic configuration file generators

Potential use case: https://github.com/ttacon/glorious/issues/49 / https://github.com/numtide/devshell/issues/47

7c6f434c

comment created time in 7 days

pull request commentNixOS/rfcs

[RFC 0067] Common override interface derivations

Meeting 1

Present were @FRidh, @7c6f434c, @Taneb and @Infinisil

Notes

Which override functions do people actually use?

  • sometimes (Haskell) you need to override source in mkDerivation and not in the builder
  • user UI: is knowledge of correct overrides needed?
    • ask for overriding the expression you see
    • but still need to understand the semantics

Stack of overridable things, e.g. for python:

  • .override for callPackage
  • .overridePythonAttrs for buildPythonPackage
  • .overrideAttrs for mkDerivation
  • .overrideDerivation for derivation

We don't want to conflate overrides of different layers with each other. Each override function should be for its specific function. Having .overrideAttrs override buildPythonPackage arguments would cross layers

To unify these layers we could give string names to each layer

  • .overrideLayer "layerName" overrides arguments of the given layer
  • This .overrideLayer function can make sure that all the other layer overrides get updated as well (no more complexity of this in each override function declaration)

With this in place, it might be possible to create a layer-inferencing override mechanism

  • .overrideLayerAuto applies attributes to the layer they are inferred from
  • This allows users to not have to know the implementation details anymore to know how things can be overridden
  • If the layer inference turns out to be ambiguous, throw an error telling the user to use .overrideLayer "<name>" instead

With this, we could also add smarts around function arguments

  • Each layer could add description values to arguments, which document their use
  • For ambiguous overrides, these descriptions are displayed
  • Can also declare supersedes-like relation, where e.g. the buildInputs of mkDerivation supersedes the buildInputs of derivation, therefore not triggering an ambiguity error

Should these overrides be a library function like lib.overrideLayer instead?

  • Doing this might allow Nix to collect Nix values which previously were kept around
  • We could also make it backwards compatible by aliasing .overrideLayer to lib.overrideLayer

Conclusions:

  • Let's not shadow .overrideAttrs arguments with .overridePythonAttrs
  • Builders may have their own override, as it mirrors the .overrideLayer approach, and we can introduce aliases later
  • However, it's very tricky to properly implement such custom .overrideFooAttrs functions, as these need to be aware of any other layers and override them all
FRidh

comment created time in 7 days

startedowncast/owncast

started time in 8 days

startedytdl-org/youtube-dl

started time in 8 days

more