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 important
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
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
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.
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
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
users
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 florent.bec...@ens-lyon.org
wrote:
On 01/09/2014
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 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 engine
Maybe a secondary git branch would be good to implement it.
Em 31/08/2014 00:32, Daniel Peebles pumpkin...@gmail.com 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
On Sat, 30 Aug 2014 23:31:42 -0400
Daniel Peebles pumpkin...@gmail.com 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
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 a
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?
Regards,
T
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 we still
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
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
- 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
17 matches
Mail list logo
