!djTaTBQyWEPRQxrPTb:nixos.org

Nixpkgs Architecture Team

222 Members
https://github.com/nixpkgs-architecture, weekly public meetings on Wednesday 15:00-16:00 UTC at https://meet.jit.si/nixpkgs-architecture52 Servers

Load older messages

SenderMessageTime
13 Jul 2022
@infinisil:matrix.orginfinisilAs implied with the "full", this can go a bit further, versions don't need to be a single string, but it can be something more abstract. A version could be a combination of: Multiple forks of a project, multiple semantic versions, different variants and more12:38:01
@kevincox:matrix.orgkevincox
In reply to @kevincox:matrix.org
I think we need to provide user overrides. For example I use a custom libvte in my system and it is important to me that all packages pick that up.

Also for overrides I think we can probably handle this basically the same we do today in all-packages.nix for now. We can think about changing those as a different project. For now it could look something like:

# foo.nix
{pkgs}: pkgs.callPackage foo/impl.nix { python = pkgs.python27 }

That isn't the prettiest but allows us to do overrides and maintains the current API. Then I think we can probably clean it up as a separate effort if we wanted too. Unless I am also missing a way that merging both projects returns a better result here.

12:38:22
@kevincox:matrix.orgkevincox
In reply to @infinisil:matrix.org
As implied with the "full", this can go a bit further, versions don't need to be a single string, but it can be something more abstract. A version could be a combination of: Multiple forks of a project, multiple semantic versions, different variants and more
At this point how is this different from regular package arguments that can be overridden? Sounds like you can have python.override { version = "2.7" } if we anted to. 		12:39:48
@kevincox:matrix.orgkevincox
In reply to @infinisil:matrix.org
As implied with the "full", this can go a bit further, versions don't need to be a single string, but it can be something more abstract. A version could be a combination of: Multiple forks of a project, multiple semantic versions, different variants and more
* At this point how is this different from regular package arguments that can be overridden? Sounds like you can have python.override { version = "2.7" } if we wanted to. 		12:39:52
@infinisil:matrix.orginfinisil
In reply to @infinisil:matrix.org
As implied with the "full", this can go a bit further, versions don't need to be a single string, but it can be something more abstract. A version could be a combination of: Multiple forks of a project, multiple semantic versions, different variants and more
And if we go even further, this can solve the problem of multiple projects having the same name, or projects renaming themselves: If two projects have the same name, in this new model this can be modeled as two versions of the same package. So this means that when there's two projects with the same name, they would both be accessible under pkgs.someName, but you then have to explicitly choose a version (no default) 		12:40:43
@infinisil:matrix.orginfinisil And when a project gets renamed, it can be represented under two names, pkgs.oldName and pkgs.newName, but underneath it can be the same thing, and share its name with other projects of the same name 12:41:29
@kevincox:matrix.orgkevincoxOne question that raises is what does hydra build? Right now hydra builds basically anything with a name. If you force a version argument then hydra won't build anything.12:41:56
@infinisil:matrix.orginfinisilThis then ties a bit more into the whole "automating attributes from the file structure"12:41:58
@infinisil:matrix.orginfinisil kevincox: That won't be a problem, what hydra builds can be changed, needs some new conventions for that 12:42:51
@infinisil:matrix.orginfinisil
In reply to @kevincox:matrix.org

Also for overrides I think we can probably handle this basically the same we do today in all-packages.nix for now. We can think about changing those as a different project. For now it could look something like:

# foo.nix
{pkgs}: pkgs.callPackage foo/impl.nix { python = pkgs.python27 }

That isn't the prettiest but allows us to do overrides and maintains the current API. Then I think we can probably clean it up as a separate effort if we wanted too. Unless I am also missing a way that merging both projects returns a better result here.

(I like that idea btw) 		12:43:39
@profpatsch:augsburg.oneprofpatschI feel like many people here are rediscovering that an attrset and a function are synonymous things :P12:44:40
@infinisil:matrix.orginfinisilOh also, this whole versioning thing then also ties into distributing nixpkgs, because it could allow third-party repos to add to the supported versions in a composition-friendly way. It also ties into allowing users to select specific versions in a generic way12:45:06
@infinisil:matrix.orginfinisil profpatsch: Well, sometimes at least 12:46:15
@infinisil:matrix.orginfinisil
In reply to @kevincox:matrix.org
At this point how is this different from regular package arguments that can be overridden? Sounds like you can have python.override { version = "2.7" } if we wanted to.
The idea would be to make it super easy to make multiple versions work. Something package authors won't have to think about unless they need it. With .override it would be a very manual process 		12:47:23
@infinisil:matrix.orginfinisilThis goes into the direction of fundamentally defining what a "package" really is. With this idea it would be something along the lines of "A derivation with a name and a version", where the version expresses notions of variants, backwards compatibility, is constrainable, etc.12:49:47
@infinisil:matrix.orginfinisilWhile this is a different problem to solve, we need to make sure we aren't solving one problem and then realizing it prevents us from solving another problem12:53:29
@infinisil:matrix.orginfinisilWith nixpkgs, so many things tie into each other it feels like12:53:57
@j-k:matrix.orgj-k
In reply to @profpatsch:augsburg.one
I feel like many people here are rediscovering that an attrset and a function are synonymous things :P
nix-repl> {}
{ }

nix-repl> {} // { hello = "world"; }
{ hello = "world"; }

nix-repl> (a: b: a + b)
«lambda @ (string):1:2»

nix-repl> (a: b: a + b) // { hello = "world"; }
error: value is a function while a set was expected

well they're a bit different

13:20:53
@whentze:matrix.orgWanja Hentzethey're different types on the surface, but in Nix in particular they're also fundamentally different, I think13:24:58
@whentze:matrix.orgWanja HentzeAFAICT, because attr names are evaluated eagerly, you can only have finitely many of them in a set13:25:27
@whentze:matrix.orgWanja Hentze so you can not build an attrset that is equivalent to a: a + "world" or something 13:26:08
@j-k:matrix.orgj-kI hope in the meeting later today we can note down a bunch of these ideas/suggestions without bike-shedding (...too much) on the call, set aside some time to test out and benchmark some of them, and ideally get a mostly prioritized list of what is most pressing or has big benefits etc. It can also be good for a new team to get a couple smaller wins out of the way to get the ball rolling although the first one might be more foundational groundwork for the team rather than collecting some of these ideas so it might have to be for a future meeting13:39:07
@infinisil:matrix.orginfinisilYeah the agenda of the first meeting will be going over team organization and onboarding new members. If there's time we can also start going into more technical discussions already though13:42:03
@sandro:supersandro.deSandro 🐧
In reply to @kevincox:matrix.org

Also for overrides I think we can probably handle this basically the same we do today in all-packages.nix for now. We can think about changing those as a different project. For now it could look something like:

# foo.nix
{pkgs}: pkgs.callPackage foo/impl.nix { python = pkgs.python27 }

That isn't the prettiest but allows us to do overrides and maintains the current API. Then I think we can probably clean it up as a separate effort if we wanted too. Unless I am also missing a way that merging both projects returns a better result here.

That is a really bad example because python 2 to 3 had many breaking changes in python itself and in many libraries. 		13:54:30
@kevincox:matrix.orgkevincox
In reply to @sandro:supersandro.de
That is a really bad example because python 2 to 3 had many breaking changes in python itself and in many libraries.
I don't follow how the breaking changes is bad in my example? You mean it would be better to be an example like libfoo = libfoo.override { withX = false} or something? 		13:56:34
@sandro:supersandro.deSandro 🐧I would recommend something that would actually work out of the box right now, just with more code. Idk. Replace python 3.10 with 3.9 or only change a minor version or something like that13:58:26
@sandro:supersandro.deSandro 🐧Or compile a go program with an older go version 13:58:57
@sandro:supersandro.deSandro 🐧Because that wouldn't require much extra work and leaves less room for side discussions. Bringing python 2 brings a lot of side discussions on the board and the python does not want to maintain an extra package set for python 2 which is only possible with old versions of most things.14:00:30
@infinisil:matrix.orginfinisil Sandro: I think that was only an example. More generically the question is "If all-packages.nix goes away, what to do with all these argument overrides in all-packages.nix" 14:03:29
@sandro:supersandro.deSandro 🐧Yeah I know, I would suggest to use uncontroversial examples without python 2.714:52:19

Show newer messages

Back to Room ListRoom Version: 9