yup. but not just search, but also an interface like nur-combined. but i’m now realizing that something like inputs.xur.helix-editor.nixosModules.default would break the flake schema as well, in addition to having to allow evaluations in the inputs block.
1 Like
Yeah, I’m glad you point this out. I think a good chunk of people in here may be using flakes primarily (myself included) and may overlook the non-flake requirements for things. Definitely important to support both.
1 Like
But just to be overly clear before I stop pestering about this side-point: My comment today was less “it is important to support both” and more “the community just completely trampled a post on one with replies on the other” - those are distinct challenges 
3 Likes
Anyway, apologies for the active derailment. A search.nixos.org with full access to a flake registry would be super cool
2 Likes
I apologise, for contributing to it even after you mentioned it. To refresh, the issue is - creating a repository for modules and packages, with a lower barrier of entry?
Circling back around to the original ask for an unofficial source for modules, I wonder if some aggregation service could be useful? Users have their nix modules in their own repositories and then can decide to let the service know they exist 
5 Likes
yeah this is exactly what i was thinking
1 Like
something similar to spicetify’s marketplace? this approach only works with GitHub, although.
another approach similar to the NUR with a repos.json where the user asks their own repository be included (which might be better, in my opinion)
1 Like
Now that is an interesting idea but how would you go about implementing it. Which is what leads me back to the XUR solution.
This is still git, so we do have the option of taking the level of service a step further:
- Take a page from the qmk project and aim for a central repo with everyones work nested in a username-based directory structure or whatever makes the most sense in this actual scenario.
- Offer one repository where these are all submodules, reducing the barrier for adding your stuff as much as possible.
- Host another which is a “render” of the first - all submodules “flattened” by CI into one repository which people can then access without having to call out to a sea of different submodule repositories and hosts.
That way we simplify the index/search challenge - opening up for doing much more “tree-wide” via the CI render step if we want, there’s always clear separation between submissions and surrounding structure - from a maintenance perspective, contributing is comparatively simple, and making use of the repo is less of a network availability & privacy consideration - from a purely structural standpoint.
3 Likes
(Heck?), the submission & update process could even be fairly simply hidden behind a simple web interface if that’s what people want. I’m just not 100% convinced that one is real when people already have a git repo with their stuff which they want to share.
Edit: “Heck” courtesy of a very protective no-swearwords setup 
1 Like
I found a current state of the art if you will:
1 Like
Ah most excellent!
I don’t quite follow why the two are mutually exclusive?
1 Like
I don’t think they are. The topic of a flake search was mentioned higher in this thread before we circled back around to the original ask of a shared unofficial modules repository.
1 Like
this makes the most sense to me. we already have similar services in flakehub, flakestry, etc. having an equivalent for modules would be great
namespacing people’s projects is a definite step up over services like the AUR. i would be concerned about the maintenance burden, though. assuming we have some moderation and quality control over what gets accepted, i feel like that would lean a bit more towards official than not. on other hand if there’s no moderation, we would basically just be in the way of maintainers doing their work (and also risk malicious actors). this basically applies to the next two points as well
i believe that in general, something like this should follow the rest of our infra and be independent. nur-combined and similar – while definitely convenient – i feel create an unneeded reliance on that repo. i also don’t know of many cases where anyone is using any significant amount of packages from it. given the popularity of both npins and flakes, i feel the nix ecosystem is to a point where grabbing a module from someone directly is really easier than ever, and should be the way to go in the future. a simple aggregation service (again, similar to flakehub/flakestry) goes perfectly with this model, while putting minimal burden on us, as well as the maintainer of each module
I understand your logic, but the result does seem somewhat flake-centric? Substituting in non-flake systems in your logic I don’t see how it holds?
while services like flakehub/flakestry do only support flakes, i wouldn’t say something for modules needs to. after all, flakes are basically always distributed through git repositories (and taking from the example of flakehub/flakestry again, this would basically be a requirement), which means that they are also easily accessible as channels. i would propose that along with the requirement of a flake with a nixosModules/etc output, a path the module(s) is also specified in metadata. this would allow for any system to easily give instructions on adding a flake to your inputs and using an output, along with adding a channel (and/or a niv/npins source) and importing it’s path with the <channel/path> syntax. the way flakes and stable nix handle modules here is so similar that i feel it would be easy to tackle both at once
2 Likes
I don’t see a point in a shared package repository when flakes already exist. A flake aggregation search that can find packages from many repositories is much more benefical.