[Nix-dev] "Package archeology" in nixpkgs

[Roger Qiu]

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?

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.
>
>

-- 
Founder of Polycademy & SnapSearch
http://polycademy.com
https://snapsearch.io
+61420925975