In this case, package gdbm will be evaluated as gdbm = callPackage ./by-name/gdbm { }
Packages with a packages.nix file, such as gd will be imported as import "${path}/packages.nix" { inherit lib noSysDirs config overlays; } res self super. This idea allows for most (all?) packages and package sets to be placed in by-name.
problems/considerations
How do we want to implement a testing infrastructure?
A lot of packages depend on packages depending on themselves for testing (A depends on B, B depends on A for testing). Within nixpkgs, this allows for every pr to check if anything has broken with a change. With the proposed split repo setup, how do we want to organize this to ensure synchronization and stability across SIG repos?
How do we want to implement alternative versions of core packages that depend on packages from another SIG?
Specifically, I noticed that cmake has a version that uses qt5Packages for its UI. Should cmakeWithGui be defined in a KDE/Qt SIG repo, or in top-level?
Some core language packages, such as rust and python3 are required to build some base utilities. How should this be managed? Under the direction of the core SIG, or the language-specific SIG? Either requires strong coordination between the two.
How are we going to keep track of updates and organize maintainers?
todo
governance
Discuss whether we want to adopt this style of package organization or use something different
Given the size of add stdenv by vlinkz · Pull Request #2 · auxolotl/core · GitHub, perhaps it would be a good idea to try to break it up into smaller reviewable pieces, however, I’m unsure how given the web of dependencies. Regardless any feedback is greatly appreciated.
code
Clean up pkgs/build-support packages and remove pkgs/top-level/all-packages.nix
Clean up python and perl package sets
Remove current passthru.tests once a replacement or course of action is decided upon
Very nice Regarding SIGs depending on one-another, what would be the downside of your example core team having a submodule reference to the work of the rust team and then update that reference when they were ready?
Which is great! I’m impressed. I guess I’ll have to get cracking on the Darwin side.
(Edit) I should say, if theres a sig_repo, like let’s say Qt tooling, and Qt maintainers are the same people updating cmakeWithGui, then I think putting it in their sig_source repo/folder takes precedence.
For the general case of “what do we do about [pkg]With[Thing1]” I’d like to propose a few things.
A naming convention. I think in general camel case for nix is more common. We could use it for the base names of things, and use underscores to indicate specific patterns/extensions. For example cmake_withGui or versioning python_v3.
If a package (let’s say [pkg1]) needs its own custom version of something, like [pkg] needs python_withNumpyAndScikit, I think by default [pkg1] in sig_source should take python, numpy, and scikit as inputs, and then mix it together themself/inline.
If a package is commonly needed but only by maintainers, then I think it should get its own section in the registry like _cmake_withGui
If its so common its user faceing (like torch_withCuda) then I think it is just placed on the registry like any other builder function. And I would argue thats where cmake_withGui specifically belongs since its probably going to be used as an input for many things.
@VlinkZ one piece of food for thought that I haven’t thought through either.
To start with an example, I think Linux bootstraps with gcc, and I know darwin bootstraps with clang.
What if we extend the job of core a bit, and also include the linux build of clang and the Darwin build of gcc. That way core.gcc can be considered non-os dependent.
We could try and do this for the maximum number of core packages.
Right, the main thing I don’t like about this setup is the fact that now the core cmake package needs to be overridden for cmakeWithGui, and any change to cmake may break cmakeWithGui. It’s definitely possible, and likely the route we’ll need to go down in order to keep the repos split up.
This is already done by the nature of how they are packaged. I feel like separating them out into separate repos would create even more overhead and require more coordination.
Okay so you’re saying this already happened in aux core because its just the way you were able to get it working? Or are you saying cmake always needs to be overridden with cmakeWithGui?
Separating what into separate repos? Core and sig_sources?
In nixpkgs, cmakeWithGui is a modification of the inputs to cmake’s default.nix. In order to get cmake to build in core without packaging qt5Packages, I removed the dependency, and thus the ability to build cmakeWithGui in core. Following this, in order to package cmakeWithGui in another SIG repo (because I don’t think packaging qt5Packages in core is a good idea if avoidable0), we’ll need to override the core cmake package definition.
The way nixpkgs has most packages, gcc and clang included means that given the same package definition, both Darwin and Linux versions of the package can be built. So there’s no including a Linux and darwin build, it’s just the gcc or clang package, which supports building on Linux and Darwin. What I meant was I don’t see any use case in separating the builds per platform, so your request for Darwin gcc and Linux clang is already met.
Okay. So what did you mean when you said “I feel like separating them out into separate repos would create even more overhead”? What was the “them”? GCC and clang each as a separate repo? Or core and sig_sources?
Okay, got it. So in terms of your earlier question:
Should cmakeWithGui be defined in a KDE/Qt SIG repo, or in top-level?
I think having it defined in a KDE/Qt SIG repo makes sense. The people who make edits to QT will probably be the same people making edits to cmakeWithGui.
Okay, and then I suppose you just manually checked (maybe it was obvious) that neither of them (like clang for Linux) depended on something that was outside of what was offered in core. Got it
Cause normally nixpkgs has those kinds of builders, but (like cmakeWithGui) they tend to just rope in whatever random thing they need without isolating it to some kind of core subset of packages.
“Them” I was referring to was Linux and Darwin versions of clang and gcc respectively not necessary for core being put into some other repo. Sorry for the confusion.
Yeah, didn’t notice anything anything that should prevent them from building, but still gotta fix some Darwin stuff so we’ll see!
.
Regarding SIGs depending on one-another, what would be the downside of your example core team having a submodule reference to the work of the rust team and then update that reference when they were ready?
