[Nix-dev] "Package archeology" in nixpkgs

[Michael Raskin]

>But with a proper database implementation, perhaps it can do full text 
>indexing on its description, or indexing on the names, and proper 
>caching mechanisms as well.
>
>Why reinvent the wheel?

What triggers reindexing?

Package name is a evaluated attribute, result of running a minimal 
expression.

Do you offer to store source code in a database? That clashes with 
versioning…

>On 1/09/2014 3:04 PM, Michael Raskin wrote:
>>> Can there be a better database rather than a text file?
>> The problem is not about a _single_ text file; the problem is that you
>> need to read some file specific to a package to find out its name, as
>> opposed to its attribute name,
>>
>> I am pretty sure we don't want to mention package versions in
>> all-packages.nix because the version in name will never match the actual
>> tarball version…
>>
>> So the solution would require some way of careful caching (note that to
>> find updates reliably you need to stat() all the files — so caching has
>> to sometimes lag behind the actual files…)
>>
>>> On 1/09/2014 4:04 AM, Michael Raskin wrote:
>>>>> On 31 August 2014 18:27, Michael Raskin <7c6f434c at mail.ru> wrote:
>>>>>> I'd say, though, that only name-based operations drop in performance
>>>>>> that way…
>>>>>>
>>>>>> Although for some strange reason we still recommend this way of using
>>>>>> Nix.
>>>>> Nix newb asks: what would be the superiour alternative, then?
>>>> nix-env -iA insted of nix-env -i
>>>>
>>>> The difference is that you use attribute name, not package name; lookup
>>>> by attribute name allows to read only all-packages.nix and relevant
>>>> sources, not entire NixPkgs tree.