-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Gambit, Gerbil, Glow #114449
Update Gambit, Gerbil, Glow #114449
Conversation
@@ -0,0 +1,433 @@ | |||
# POP: Pure Object Prototypes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(There is a lot of preferring not to die on this hill in my position, and giving up on reasonably quick decision making in Nixpkgs, and giving up on consistency of decision making in Nixpkgs)
My impression is that a lot of extension mechanisms in Nixpkgs are like that because they try to pretend Nix is not a computationally-general-purpose programming language. POP has to come out and pop the bubble of pretence. Which is even a plus in my opinion, but raises the risks.
On the other hand, one extension mechanism that at least recognises its computational power is modules. Which are primarily used for NixOS but now sometimes also inside Nixpkgs. I think it would be nice to include them if you already compare to other extension mechanisms. Additionally, the thing that is popular to dislike about modules is their performance overhead. It's kind of worrying that the question of runtime CPU/RAM consumption is not prominently mentioned…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I admit I never hacked modules, so I cannot comment at the moment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that I created a PR just for POP #116275
I don't understand the failure in the |
3ee10fa
to
5b8304d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PTAL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a small nit. The lib is a bit out of my scope.
8881014
to
3aa2b5f
Compare
Did all the requested changes, and also merged in the changes from #113405. PTAL. |
@fare perhaps the POP-related stuff should be moved to a separate commit and possibly RFC? I'm not sure we need yet another extension mechanism (I'm not familiar with object systems). My preference would be to have this PR do the updates/refactoring with what we have currently and open another PR to add new functions to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After a first pass of pop.md
, I like the idea, though I am one of those people who know pure lazy functional programming well and not object systems 😆. I definitely think it warrants further discussion outside of this Nixpkgs PR since if implemented could lead to wider changes and unification in the various heterogeneous extension mechanisms present in Nixpkgs.
all their transitive dependencies, so as to manually compute and use | ||
the precedence list, and maintain it as the code evolves. | ||
This is a modularity disaster that prevents programmers from abstracting | ||
over the details of which prototype requires what other prototype when used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related: shared flake overrides NixOS/nix#4004
overrides to a super object of type `B` sufficient to turn it into | ||
an object of type `A`: | ||
|
||
type Extension = A: B: Exists C: A B -> C | B // C <: A <: B; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps explain a bit about the use of existential types here or use forall
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better?
and the `defaults` take precedence from left to right, then if not found | ||
the `bottomDefaults` are consulted from right to left. | ||
|
||
## TODO for POP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good to have in the RFC!
I could move the Actually, I initially wanted to put pop inside gerbil... but then I found I couldn't extend gerbil with pop if pop was itself in gerbil (or at least it was trickier and uglier). So I moved it to lib, where it belongs eventually. I even started an RFC (82) about having an "official" way to deal with such "experimental" libraries, but it doesn't look like this will ever happen. |
7f8970f
to
3aa2b5f
Compare
@SuperSandro2000 should |
No, nixpkgs-hammering does not have such a feature right now.
probably not. |
@@ -19,21 +20,22 @@ rec { | |||
--replace "$(grep '^PACKAGE_VERSION=.*$' configure)" 'PACKAGE_VERSION="v${git-version}"' \ | |||
--replace "$(grep '^PACKAGE_STRING=.*$' configure)" 'PACKAGE_STRING="Gambit v${git-version}"' ; | |||
''; | |||
targets = "arm,java,js,php,python,riscv-32,riscv-64,ruby,x86,x86-64"; # eats 100% cpu on _digest | |||
modules = false; | |||
targets = "js"; # arm,java,js,php,python,riscv-32,riscv-64,ruby,x86,x86-64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why removal of arm/x86-64 native targets? Purely for build time reasons?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are various failures when building "modules" that don't have time to address. Also, while basically working, these backends are missing many features, and they are receiving to love at the moment. Hopefully at some point someone will make them really work, but until then, it's too much hassle for too little upside.
Like the many Jsonnet-style object systems already in Nix, pop combines instance field values and composable prototype information in a same attrset. However pop also implements CLOS-style DAG-based multiple inheritance.
Also use foldr when it makes sense.
Add an indirection between gerbil package parameters and nix packages computed from those parameters, so overlays can easily override the former. Use POP to override packages when the sha256 doesn't match. Run unit-tests of gerbil packages (not integration tests). Fix binaries for gerbil packages. Fix support for gerbil packages including binaries.
I still don't get it (and we don't have enough shepherd volunteers to reopen global-POP RFC so it makes sense to revisit the least-impact approach). Let POP live in gerbil directory tree, every version of Gerbil just imports POP and uses it, and then reexports it. If you need POP to extend Gerbil, you just grab it (and it doesn't matter where you grab it from, it is the same import) I guess you could also have |
As in put it in the |
Nix is lazy, so |
Release v0.3.1
Update Gambit, Gerbil and Glow with Glow's first release v0.1.0.
Also include some changes in lib that Gerbil support relies on, notably including the POP object system, which by now is rather stable and proven for the purpose of building coherent locally modified sets of packages.
Motivation for this change
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)