auxolotl/labs
26
12
Fork 16
Code Issues 6 Pull requests 10 Projects Releases Packages Wiki Activity Actions

WIP: Package selector predicates #58

Draft
RossSmyth wants to merge 2 commits from RossSmyth/labs:predicates into main
pull from: RossSmyth/labs:predicates
merge into: auxolotl:main
Conversation 3 Commits 2 Files changed 3 +48 -28
RossSmyth commented 2025-12-04 19:22:47 +00:00
Contributor
Copy link

uhhhhhhhhhhhhhhhhhhhhhhhhh

uhhhhhhhhhhhhhhhhhhhhhhhhh
RossSmyth added 2 commits 2025-12-04 19:22:48 +00:00
jakehamilton reviewed 2025-12-04 19:38:33 +00:00
jakehamilton left a comment
Owner
Copy link

Interesting idea! I think there may be some utility here for easily selecting a package + version, but I am not sure this current iteration is the right solution.

Interesting idea! I think there may be some utility here for easily selecting a package + version, but I am not sure this current iteration is the right solution.
tidepool/src/lib/packages.nix
@ -16,1 +16,4 @@
# Selects an individual dependency based upon the user's provided predicate selector
#
# The runtime must provide a package set, then the name and selector are provided by the package
jakehamilton commented 2025-12-04 19:33:10 +00:00
Owner
Copy link

It seems this isn't a package set, but a package alias that is required

It seems this isn't a package set, but a package alias that is required
RossSmyth commented 2025-12-04 19:57:31 +00:00
Author
Contributor
Copy link

Yeah I'm unsure of the names of each attribute. But the idea is that the module system supplies something like packages.foundation as the default package set that the selectors then use.

Yeah I'm unsure of the names of each attribute. But the idea is that the module system supplies something like `packages.foundation` as the default package set that the selectors then use.
jakehamilton commented 2025-12-04 23:25:16 +00:00
Owner
Copy link

Ah, I see. The naming I have been using is:

  • config.packages is the package set
  • config.packages.<namespace> are namespaces in the package set
  • config.packages.<namespace>.<name> are package aliases which contain all the different versions of that alias's package
Ah, I see. The naming I have been using is: - `config.packages` is the package set - `config.packages.<namespace>` are namespaces in the package set - `config.packages.<namespace>.<name>` are package aliases which contain all the different versions of that alias's package
tidepool/src/lib/packages.nix
@ -17,0 +25,4 @@
# Name
# ↓
# Pkgs -> String -> ( PackageVersions -> SelectedPkg ) -> SelectedPkg
select = pkgs: name: selector: selector pkgs.${name};
jakehamilton commented 2025-12-04 19:34:13 +00:00
Owner
Copy link

How does this handle namespaces such as packages.gnome.*?

How does this handle namespaces such as `packages.gnome.*`?
RossSmyth commented 2025-12-04 19:57:46 +00:00
Author
Contributor
Copy link

Since those do not exist yet, it does not.

Since those do not exist yet, it does not.
jakehamilton commented 2025-12-04 23:22:39 +00:00
Owner
Copy link

We do have namespaces currently. For example packages.foundation. We should make sure everything is compatible with this structure.

We do have namespaces currently. For example `packages.foundation`. We should make sure everything is compatible with this structure.
tidepool/src/lib/types.nix
@ -431,3 +431,3 @@
dependencies =
let
type = lib.types.withCheck lib.types.raw lib.types.package.children.final.check;
type = lib.function (lib.types.withCheck lib.types.raw lib.types.package.children.final.check);
jakehamilton commented 2025-12-04 19:36:36 +00:00
Owner
Copy link

I don't think we should require this to be a function. We need to be able to set values here, not just pick names from the current package set. Part of the original design is that we allow pulling packages from other sources that are outside the package set and assigning them as dependencies. We don't want to lose that. Plus the niceness around merging package config.

I don't think we should require this to be a function. We need to be able to set values here, not just pick names from the current package set. Part of the original design is that we allow pulling packages from other sources that are outside the package set and assigning them as dependencies. We don't want to lose that. Plus the niceness around merging package config.
RossSmyth commented 2025-12-04 19:58:32 +00:00
Author
Contributor
Copy link

Ok

Ok
tidepool/src/packages/foundation/gnugrep/versions/3.11-stage1.nix
@ -61,3 +52,1 @@
xz = packages.foundation.xz.versions."5.4.3-bootstrap";
gcc = packages.foundation.gcc.versions."13.2.0-bootstrap";
binutils = packages.foundation.binutils.versions."2.41-bootstrap";
gnumake = p: p."4.4.1-bootstrap";
jakehamilton commented 2025-12-04 19:37:30 +00:00
Owner
Copy link

I don't quite see how this is better, but perhaps I am not considering the right use case?

I don't quite see how this is better, but perhaps I am not considering the right use case?
RossSmyth commented 2025-12-04 20:10:30 +00:00
Author
Contributor
Copy link

The idea to to basically decouple the package definition from the exact package set it depends on by default. The way tidepool is defined right now, I don't think it makes much difference besides just not having to repeat packages.foundation.${package}.version for every dependency.

But for example it would be good if at some point rather than essentially pinning each package to a specific version as is done now, they would like on something like packages.tidepool.gzip.stable, or however it is pronounced, and then using these selector predicates would make it easier to swap out the exact underlying package set used since it would just be written as gzip = p: p.stable.

Then ideally we could scope the package sets used for different package sets. So the foundation packages would have the underlying package set as packages.foundation, and probably make each stage a separate set so that we don't need to manually update each package a bootstrap update occurs.

The idea to to basically decouple the package definition from the exact package set it depends on by default. The way tidepool is defined right now, I don't think it makes much difference besides just not having to repeat `packages.foundation.${package}.version` for every dependency. But for example it would be good if at some point rather than essentially pinning each package to a specific version as is done now, they would like on something like `packages.tidepool.gzip.stable`, or however it is pronounced, and then using these selector predicates would make it easier to swap out the exact underlying package set used since it would just be written as `gzip = p: p.stable`. Then ideally we could scope the package sets used for different package sets. So the foundation packages would have the underlying package set as `packages.foundation`, and probably make each stage a separate set so that we don't need to manually update each package a bootstrap update occurs.
jakehamilton commented 2025-12-04 23:21:39 +00:00
Owner
Copy link

Isn't this already supported via the concept of package aliases and their resolution? We have a switch for letting users pick stable vs latest and maintainers would simply use the alias itself so that it can resolve appropriately. The alternative of locking versions explicitly is a separate use case mostly meant for historic versions of packages or for allowing explicit overrides as needed.

Isn't this already supported via the concept of package aliases and their resolution? We have a switch for letting users pick stable vs latest and maintainers would simply use the alias itself so that it can resolve appropriately. The alternative of locking versions explicitly is a separate use case mostly meant for historic versions of packages or for allowing explicit overrides as needed.
srd424 commented 2025-12-25 17:04:50 +00:00
Member
Copy link

I know this is marked WIP, but I stuffed it through hydra anyway .. it's not happy :( https://hydra.aux-cache.dev/jobset/aux-prs/labs-pr58#tabs-errors

Should lib.function be lib.types.function?

I know this is marked WIP, but I stuffed it through hydra anyway .. it's not happy :( https://hydra.aux-cache.dev/jobset/aux-prs/labs-pr58#tabs-errors Should `lib.function` be `lib.types.function`?
RossSmyth commented 2025-12-26 18:34:28 +00:00
Author
Contributor
Copy link

Yeah. This is currently half-baked so I would not expect Hydra to be happy with it.

Yeah. This is currently half-baked so I would not expect Hydra to be happy with it.
👍 1
This pull request is marked as a work in progress.
This branch is out-of-date with the base branch
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u predicates:RossSmyth-predicates
git checkout RossSmyth-predicates

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git checkout main
git merge --no-ff RossSmyth-predicates
git checkout RossSmyth-predicates
git rebase main
git checkout main
git merge --ff-only RossSmyth-predicates
git checkout RossSmyth-predicates
git rebase main
git checkout main
git merge --no-ff RossSmyth-predicates
git checkout main
git merge --squash RossSmyth-predicates
git checkout main
git merge --ff-only RossSmyth-predicates
git checkout main
git merge RossSmyth-predicates
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
  
Compat
Breaking
Breaking change that won't be backward compatible

  
Kind/Bug

Something is not working

  
Kind/Documentation

Documentation changes

  
Kind/Enhancement

Improve existing functionality

  
Kind/Feature

New functionality

  
Kind/Security

This is security issue

  
Kind/Testing

Issue or pull request related to testing

  
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Medium
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

No labels
Compat
Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: auxolotl/labs#58
No description provided.
Delete branch "RossSmyth/labs:predicates"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?