2016-01-08 0:34 GMT+00:00 Jonn Mostovoy <[email protected]>: > Tomasz, > > Any group of packages that depend on a runtime or maintained as whole for > different reasons. > > Kde, Gnome, haskellPackages. > Still don't see the value in it. I would just prefix them with haskellPackages-<name>, pythonPackages-<name>.
> In fact, go through the directory tree and read some deep expressions, > you'll see the usefulness of it yourself! > Will look thanks. > You are complaining about ambiguity in categories, why not to add more > dimensions to the metadata and utility to query values of those? Some > categories are better than no categories, are better than some things > categorized and some others not categorized. > I completely agree! I think all metadata should be in metadata attribute in nix file :-) > On Jan 8, 2016 1:21 AM, "Tomasz Czyż" <[email protected]> wrote: > >> @Luca: >> Why haproxy is more a tool and sigproxd is more application than tool? >> ./tools/networking/haproxy >> ./applications/networking/siproxd >> Why there is no common networking category? (simple, because most >> programs match multiple categories) >> >> Same for "groups", why gnome-terminal is more gnome and not more terminal? >> >> @Jonn >> Could you give an example? I'm using nix ~0.5year and not familiar with >> all internals yet. >> >> 2016-01-08 0:15 GMT+00:00 Jonn Mostovoy <[email protected]>: >> >>> Your approach holds for applications, but fails for libraries, or >>> rather, for packages that are part of different ecosystems. >>> >>> There are some packages that just can't be taken out of their respective >>> "contexts" without introducing indirection. >>> >>> I agree, however, that "packages in themselves" *can* be flattened, I'm >>> not sure they should be though. Giving an option for a user to go over >>> interesting to him parts of nixpkgs over tea, clicking with mouse and >>> scrolling, learning about what's packaged and what's not might be not worth >>> taking away. >>> On Jan 8, 2016 1:04 AM, "Tomasz Czyż" <[email protected]> wrote: >>> >>>> After playing for a while with a nixpkgs repo I have impression that >>>> categories/directories are just waste of time. >>>> >>>> * Have to be maintained >>>> * Harder to find things >>>> * Lack of any package manager which tells about it >>>> >>>> Each time I want to find a package name I do >>>> * find -name '*name*' >>>> or use github search to locate files in repo. >>>> >>>> From maintaining perspective: >>>> >>>> (for x in `ls`; do n=$(ls $x|wc -l);echo "$n - $x";done)|sort -n >>>> 1 - backup >>>> 2 - inferno >>>> 2 - search >>>> 3 - gis >>>> 4 - display-managers >>>> 10 - altcoins >>>> 11 - science >>>> 11 - taxes >>>> 20 - virtualization >>>> 25 - kde-apps-15.12 >>>> 27 - office >>>> 41 - version-management >>>> 41 - window-managers >>>> 42 - networking >>>> 59 - video >>>> 60 - editors >>>> 85 - graphics >>>> 186 - audio >>>> 224 - misc >>>> >>>> Do you see that? It's hard to define all those categories levels, some >>>> of directories have subdirectories (like applications) other not (servers). >>>> It's hard to follow. >>>> Most people know the name of the software, if not, they probably use >>>> google to find it, not using categories. >>>> >>>> Let's make the layout more clear, more accessible and easy to follow. >>>> >>>> What do you think about moving all packages into flat namespace? >>>> >>>> Let's say you have >>>> >>>> pkgs/package1/default.nix >>>> pkgs/package2/default.nix >>>> >>>> or even better: >>>> >>>> pkgs/my-package.nix >>>> pkgs/gcc.nix >>>> pkgs/gcc-5.0.nix >>>> >>>> then, you can autogenerate top-level.pkgs >>>> >>>> I'm happy to help implementing that. >>>> >>>> _______________________________________________ >>>> nix-dev mailing list >>>> [email protected] >>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>> >>>> >> >> >> -- >> Tomasz Czyż >> > -- Tomasz Czyż
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
