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 > >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
