Conversation
| @@ -0,0 +1,433 @@ | |||
| # POP: Pure Object Prototypes | |||
There was a problem hiding this comment.
(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.
I admit I never hacked modules, so I cannot comment at the moment.
There was a problem hiding this comment.
Note that I created a PR just for POP #116275
|
I don't understand the failure in the |
3ee10fa to
5b8304d
Compare
SuperSandro2000
left a comment
There was a problem hiding this comment.
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 |
siraben
left a comment
There was a problem hiding this comment.
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.
lib/pop.md
Outdated
lib/pop.md
Outdated
There was a problem hiding this comment.
Perhaps explain a bit about the use of existential types here or use forall
lib/pop.md
Outdated
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
Why removal of arm/x86-64 native targets? Purely for build time reasons?
There was a problem hiding this comment.
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
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)