[DRAFT] Dynamic Libraries

[interacsion]

No description provided.

[jonringer]

The composition of the different repositories will occur through overlays, from the nix perspective, the instantiated package set should be very similar to nixpkgs

[interacsion]

Hmm, I didn't consider that. I guess this paragraph is void then

[jonringer]

This is still a valid concern with "flakes" (not specifically, just that they make it easy), where you can reference very divergent DAGs for the same "package". E.g. two versions of openssl

[GrizzlT]

The composition of the different repositories will occur through overlays, from the nix perspective, the instantiated package set should be very similar to nixpkgs

@jonringer Doesn't this idea pose a conflict with the idea of atoms? Something like corepkgs will inevitably change over time. And an overlay that depends on corepkgs cannot always magically assume that what it needs is available. I think you would need some kind of compatibility-checking either way.

I've been working on a prototype that allows for different corepkgs revisions to be used at the same time, this is good for easy predictability but would hit the problem described here. Maybe if there's a versioning system and good public-facing documentation of the packages in corepkgs (and available attributes) in place both issues could be addressed? Version-checking the different repos guarantees predictability but also makes sure there's no conflicting dependencies. Sound right?

[interacsion]

I raised this point briefly in the discord and I tend to agree. We would potentially have to implement some sort of dependency resolver for Atoms.

[jonringer]

Similar to flakes, I will probably provide multiple entrypoints. But at the end of the day, corepkgs will just be a "nix package set"

[interacsion]

We can be open to including metadata required for Atoms to work, no?

[jonringer]

Yes, I'm fine with non-intrusive inclusion.

[GrizzlT]

Similar to flakes, I will probably provide multiple entrypoints. But at the end of the day, corepkgs will just be a "nix package set"

I'll take this into consideration for my prototype. How will all the overlays be collected together?

[nrdxp]

My original plan was to not invade Jon's design space really at all, and instead just build up something that would naturally compliment it as it develops.

I raised this point briefly in the discord and I tend to agree. We would potentially have to implement some sort of dependency resolver for Atoms.

That's the idea, yes. For simplicities sake, and for simple projects, a "shallow" algorithm which simply locks direct dependencies based on a version request should suffice. For large derivations, a deep algo which descends the entire dependency tree might come in handy.

Either way, the point of atoms is the keep the dependency tree well abstracted and explicit. There is a lot of incidental complexity involved with all the overlaying and overriding going on everywhere, and the tight coupling between a specific checkout of nixpkgs and virtually everything else sort of makes this feel unavoidable.

atoms should alleviate this, and make updating the package repository more of a granular step by step process, instead of an all or nothing slog. At least, that's what I'm betting on, and as the project grows in complexity, and if I suceed, hopefully that becomes clear all on its own.