D'oh! Looks like I need to work on my copy-paste skills. Thanks!
Rich
On Mon, Nov 5, 2012 at 9:52 AM, Andres Loeh wrote:
> Hi Richard.
>
> > pkgs : {
>
>
> You refer to this argument ...
>
> > packageOverrides = self : rec {
>
>
> but you should refer to t
Hi Richard.
> pkgs : {
You refer to this argument ...
> packageOverrides = self : rec {
but you should refer to this one.
> myHaskellPackages =
> let callPackage = pkgs.lib.callPackageWith myHaskellPackages; in
> pkgs.haskellPackages.overr
On Thu, Nov 1, 2012 at 12:14 AM, Andres Loeh wrote:
> Hi Richard.
>
> What Peter says is true. And ultimately, you should be motivated to
> just submit your new packages as a pull request to nixpkgs.
>
> However, I'd like to point out that there's also a somewhat less
> invasive way to test your o
Thanks Andres. This is what I was looking for. I tried something
similar but got caught up with it picking up the dependencies.
Rich
On Thu, Nov 1, 2012 at 12:14 AM, Andres Loeh wrote:
> Hi Richard.
>
> What Peter says is true. And ultimately, you should be motivated to
> just submit your new
Hi Richard.
What Peter says is true. And ultimately, you should be motivated to
just submit your new packages as a pull request to nixpkgs.
However, I'd like to point out that there's also a somewhat less
invasive way to test your own Haskell packages.
There's a nixpkgs configuration file at ~/.
Hi Daniel,
let's talk about the problems & concerns.
Right now its maintained by me only.
the solver is
- a proof of a concept, but works
- written in Nix (which is not the right language, and its little bit
slow, but bearable, and hard to read and understand what is going on
exactl
This works well. I found that if I didn't have the channel added, it
was building everything from scratch. So I also added the channel and
then nix-env picked up the binaries correctly and picked up my added
package. Is this ok? Just want to make sure I'm not going to run
into something terribl
I don't disagree, but from the BUGS section of the haskell-overlay[1]
"Oh, there are many. build tools were not defined by cabal files in
the past which is why tools like happy have to added as buildinputs
manually (see default.nix file of the overlay). If you have 2 month of
free time - what abou
I'm interested in figuring out what is standing in the way of getting
hack-nix as the standard way of doing things. From my very naive point of
view, that is what I would want as the end user. This deal of having to
create a nix expression for every package, and for every version of that
package
Thanks, I think I'll give this a try. hack-nix is more comprehensive,
but I'd like to see if I can contribute to the community.
On Wed, Oct 31, 2012 at 2:01 PM, Peter Simons wrote:
> Hi Richard,
>
> > It seems like ~/.nix-defexpr is the place I should add anything custom.
>
> yes, that is true.
Hi Richard,
> It seems like ~/.nix-defexpr is the place I should add anything custom.
yes, that is true. Personally, I have a checked-out copy of the Git
repository from http://github.com/nixos/nixpkgs at that location. Adding
'boomerang' is then just a matter of running the commands:
$ cd .n
You can use hack-nix instead, it packages everything found on hackage.
The alternative is patch nixpkgs and contribute the missing packages.
The Nix wiki should talk about both way - I maintain the hack-nix way
only.
If you have trouble about hack-nix contact me. I can provide access to
an SSH ac
I've got almost everything setup for my Haskell project, but there's
one last thing I need help figuring out. There are several packages
in cabal that aren't in nixpkgs (boomerang, web-routes, lens) that I
would like to use.
It seems like ~/.nix-defexpr is the place I should add anything
custom.
13 matches
Mail list logo
