That was actually my original motivation for doing this. I looked for the
oldest GHC I could find (0.26) and it still wanted to be compiled by itself,
although it said that HBC could do it if you put in more effort. I was hoping
to get the binary bootstrapping out of the GHC build pipeline under
On 31/08/2014 04:31, Daniel Peebles wrote:
> I've had a sudden urge to do some Haskell archeology and that led me
> to a question about how we feel "philosophically" about keeping
> abandoned projects and old versions of live projects in nixpkgs. I
> think it could be valuable to preserve importan
>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?
Because every package is a piece of code in Nix programming language.
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?
> T
I think the name and the attribute name could be named with better
names, to prevent confusion. Perhaps a "label" and "path"/"fully
qualified path". The name is just really used for fuzzy search which I
believe is there for convenience for the operator. Like the difference
between a search engi
The CI system can support this process, every time a new package is
built, its then triggers a reindex and mutation of the database, which
is then supplied via the channel.
On 1/09/2014 7:22 PM, Vladimír C(unát wrote:
On 09/01/2014 11:24 AM, Michael Raskin wrote:
What triggers reindexing?
I
Don't forget the nix-env -u case which updates based on name (in fact, that
kinda sucks for sub-attributes like python packages, there are lots of
attributes mapping to the same names).
Wout.
On Mon, Sep 1, 2014 at 10:44 PM, Florent Becker wrote:
>
> On 01/09/2014 11:22, Vladimír Čunát wrote:
On 01/09/2014 11:22, Vladimír Čunát wrote:
> I suggest we distribute the database with the channel, similarly
> to the command-not-found database.
Can't command-not-found suggest using nix-env -iA rather than nix-env
-i? That would be one indirection less for that use case, and teach new
user
On 09/01/2014 11:24 AM, Michael Raskin wrote:
What triggers reindexing?
I suggest we distribute the database with the channel, similarly to the
command-not-found database. IMO it is mostly channel users that use
installing by name, not developers who build from modified git tree.
Vladimir
>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
expres
>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-p
Can there be a better database rather than a text file?
On 1/09/2014 4:04 AM, Michael Raskin wrote:
>> On 31 August 2014 18:27, Michael Raskin <7c6f4...@mail.ru> wrote:
>>> I'd say, though, that only name-based operations drop in performance
>>> that way…
>>>
>>> Although for some strange reason w
>On 31 August 2014 18:27, Michael Raskin <7c6f4...@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
On 31 August 2014 18:27, Michael Raskin <7c6f4...@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?
Regar
>> How do people feel about this? Is it something I should maintain
>> independently of nixpkgs or does it belong in the main repo?
>
>... please keep it out of the main Nixpkgs, at least for now. Reason
>is that currently Nix performance drops linearly with the number of
>packages. Until we have
On Sat, 30 Aug 2014 23:31:42 -0400
Daniel Peebles wrote:
> I've had a sudden urge to do some Haskell archeology and that led me
> to a question about how we feel "philosophically" about keeping
> abandoned projects and old versions of live projects in nixpkgs.
I think it's a very good idea, but
Maybe a secondary git branch would be good to implement it.
Em 31/08/2014 00:32, "Daniel Peebles" escreveu:
> Hi all,
>
> I've had a sudden urge to do some Haskell archeology and that led me
> to a question about how we feel "philosophically" about keeping
> abandoned projects and old versions of
> - NHC: can build it with HBC
According to [1], it can be bootstrapped via C. If I remember
correctly, I successfully built it this way in the past (outside of
NixOS).
> How do people feel about this?
I think it’s a great idea. I always wanted to try HBI, which “supports
the full language at
Hi all,
I've had a sudden urge to do some Haskell archeology and that led me
to a question about how we feel "philosophically" about keeping
abandoned projects and old versions of live projects in nixpkgs. I
think it could be valuable to preserve important pieces of Haskell
history (and perhaps ot
19 matches
Mail list logo
