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

[Tomasz Czyż]

2016-01-08 0:34 GMT+00:00 Jonn Mostovoy <jm at memorici.de>:

> 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ż" <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ż
>>
>


-- 
Tomasz Czyż
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160108/f90f7175/attachment-0001.html