[Nix-dev] Flattening pkgs tree in nixpkgs/pkgs

[Spencer Whitt]

-1 on the meta tags approach.

1) Resolving meta tags would require evaluating all of nixpkgs, which we
should definitely be moving away from
2) Meta tags can be easily misspelled without being easily detected. Even
meta.licenses and meta.platforms are frequently committed while misspelled,
leading to evaluation issues...
3) Due to the flexibility of tags, they are more difficult to manage than
directories.
4) Tags do not solve the maintenance issues raised by Luca. A maintainer
may want packages to be located in the same directory for ease of
maintenance, but with tags they're scattered, albeit tagged.

If you flatten the package hierarchy, you still need to use find/grep to
locate your package. That's no better than using find/grep to locate your
package today. I see little benefit to any of the changes proposed here and
significant cost in merge conflicts and churn.

On Sun, Jan 10, 2016 at 7:24 AM, zimbatm <zimbatm at zimbatm.com> wrote:

> Okay, now we just need *someone* to implement a proof of concept :p
>
> On Sun, 10 Jan 2016 at 11:13 ikrek vagyunk <ikervagyok at gmail.com> wrote:
>
>> dear fellow nixers,
>>
>> i  followed this discussion and would like to propose (the already
>> proposed) way of sorting packages alphabetically and then add some
>> meta-tags. every package should be in a directory, just like today, with
>> default.nix and all other files needed for that exact package.
>>
>> pros:
>> - would be mostly just automatically moving the current package set
>> around and adding meta-tags derived from the current directory structure
>> - all-packages.nix can invoke any package by doing:
>>   callPackage name {whatever options you want};
>> - if you add a new package, you instantly know where to put it
>> - if we would break the 1000 files github limit - or any other reasonable
>> directory-size limit - we easily can create subdirectories and move the
>> files accordingly (without any effort)
>>   /pkgs/a/ -> /pkgs/a and /pkgs/a/a_ (where underscore represents the
>> most used second character in /pkgs/a and all packages with that prefix
>> could be moved automatically - note: all-packages.nix wouldn't need to
>> change)
>> - we would need some new meta-attributes (and they would be nice, i think
>> - querying for any kind of remote shell that is written in haskell or
>> python would be sth like: nix-query shell AND server AND (haskell OR
>> python))
>>   attributes would be: meta.languages, meta.categories,...
>>
>> cons:
>> - possible recompilation-issues whenever we move packages to
>> subdirectories
>> - changes to callPackage/... may be necessary, if we don't want to
>> manually write the directories
>> - gnome/kde/haskell/... packages would be scattered around
>>
>> even though i'm not as good with nix/nixos internals, i believe this is
>> the easiest way to manage things - correct me if i'm wrong (also add
>> anything, if you think i'm right, but the proposal is not clever enough ;))
>>
>>
>> anyway: keep up the good work ;)
>> regards, ikervagyok
>>
>> p.s.: about users being capable of reading/writing nix-files: i convinced
>> three people to use nixos, none of them really use it though - so from my
>> position it seems like every real user is very capable - and we don't need
>> to worry much about non-nix-file-reading users...
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160110/265378e3/attachment.html