[Nix-dev] Flattening pkgs tree in nixpkgs/pkgs
Jonn Mostovoy
jm at memorici.de
Fri Jan 8 01:34:41 CET 2016
Tomasz,
Any group of packages that depend on a runtime or maintained as whole for
different reasons.
Kde, Gnome, haskellPackages.
In fact, go through the directory tree and read some deep expressions,
you'll see the usefulness of it yourself!
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.
On Jan 8, 2016 1:21 AM, "Tomasz Czyż" <tomasz.czyz at gmail.com> 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 <jm at memorici.de>:
>
>> 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ż" <tomasz.czyz at gmail.com> 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
>>> nix-dev at lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>>
>
>
> --
> Tomasz Czyż
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160108/654b186e/attachment.html
More information about the nix-dev
mailing list