Skip to content
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

Move top-level packages to a pkgs attribute #51

Open
fgaz opened this issue Jul 22, 2018 · 10 comments
Open

Move top-level packages to a pkgs attribute #51

fgaz opened this issue Jul 22, 2018 · 10 comments

Comments

@fgaz
Copy link
Contributor

fgaz commented Jul 22, 2018

Followup from #27 (comment)

I propose to move all the packages from the top-level to a pkgs attribute, so that default.nix only contains pkgs, lib, modules, and overlays.

Pros:

  • more extensible and maintainable
  • avoids workarounds like this or this

Cons:

  • slightly more complicated basic structure
  • five more characters for the user to type
    • can be avoided by making the packages available at the top-level but using this repo's code, not individually on each nur-packages
@infinisil
Copy link
Contributor

can be avoided by making the packages available at the top-level but using this repo's code, not individually on each nur-packages

You mean like nur.{pkgs,modules,overlays,lib}.paul.foo instead of nur.repos.paul.{pkgs,modules,overlays,lib}.foo? That might be pretty neat.

@fgaz
Copy link
Contributor Author

fgaz commented Jul 22, 2018

I meant nur.repos.paul.foo (but done at this repo's level) in addition to nur.repos.paul.{pkgs,modules,overlays,lib}.foo, but nur.{pkgs,modules,overlays,lib}.paul.foo sounds even better! It's even one character less than the original ;-)

@Mic92
Copy link
Member

Mic92 commented Jul 23, 2018

As compatibility layer we could check for the existence of pkgs in the repository and fallback to top-level otherwise.

@tilpner
Copy link
Contributor

tilpner commented Jul 23, 2018

I'm not convinced that compatibility layer would be worth the extra complexity (and documentation effort). Right now, it's cheap to break the interface, only a dozen repos would have to be updated (again).

@zimbatm
Copy link
Member

zimbatm commented Jul 24, 2018

Normally I would expect to be able to nix-build the repo top-level. If additional arguments are introduced it's going to make harder to provide defaults for all of them.

@tilpner
Copy link
Contributor

tilpner commented Jul 24, 2018

@zimbatm What argument are you talking about? Implementing this should not add any arguments, just alter the structure of the returned attrset.

@zimbatm
Copy link
Member

zimbatm commented Jul 24, 2018

doh, nevermind. I was still thinking of { pkgs, lib, ...} as the recommended default.nix arguments.

@fgaz
Copy link
Contributor Author

fgaz commented Aug 11, 2018

Bump

@zimbatm
Copy link
Member

zimbatm commented Aug 12, 2018

How about we introduce multiple types of repositories? Instead of cramming everything into one.

The details can vary

@rycee
Copy link
Member

rycee commented Sep 2, 2019

FWIW I'm not so very fond of the nur.{pkgs,modules,overlays,lib}.paul.foo naming scheme since it seems to limit me to one of a few approved "top-level" namespaces.

So if I wanted to add a set of Home Manager modules I wouldn't know what to choose. I guess nur.modules.rycee.home-manager.foo might work but then it all gets mixed up with NixOS modules (and I also happen to have a NixOS module named home-manager 🙂).

I do think it is a good idea to endorse a pkgs attribute under which all packages go, i.e., nur.repos.paul.pkgs.foo.

bb010g added a commit to bb010g/dotfiles that referenced this issue Oct 30, 2019
home.stateVersion is now specified.

[meta] diff.jq: Easier to run

[private] Migrate to private-home.nix

private-home.nix is a cleaner private.nix replacement, taking advantage
of how normal NixOS imports work.

[nur] Cleaning & experimental syntax

nur-bb010g continues to try to figure out how it'll work long-term.

The experimental nix-community/NUR#51
`nur.{lib,modules,overlays,pkgs}.${repo}` layout is now supported to see
how it feels with mostly my repo. Seems not have any issues for now.

[packages] ipscan: disabled until Nixpkgs upstreaming is figured out

[programs] beets: Cleaner config

[programs] redshift: Cleaner config

[sources] update (6)

firefox-nightly: 2019-10-19 -> 2019-10-30
lorri: 2019-08-20 -> 2019-10-30
lorri-unstable: 2019-10-07 -> 2019-10-30
niv: 2019-09-23 -> 2019-10-30
nixpkgs: 19.03 -> 19.09 (2019-10-07 -> 2019-10-27)
nixpkgs-unstable: 2019-09-25 -> 2019-10-23
milahu pushed a commit to milahu/NUR that referenced this issue Aug 6, 2023
…hub_actions/actions/checkout-2.3.5

Bump actions/checkout from 2.3.4 to 2.3.5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants