Hi all,
this is a follow-up on the discussion about a set of controversial
commits[0]. By controversial I mean that two or more developers don't agree
on the implementation.
Let's ignore the context of disagreement and anything else not relevant to
the commits in question that are already in any
I don’t think we need 24 hour windows or anything. Don’t revert something that
is just broken for trivial concerns if the other dev is actively responding,
but don’t wait if something is fundamentally broken. My workflow here would be
“see bad commit, revert, open discussion on the revert
Fundamentally broken is most of the times opinionated. If a committed
package update breaks 1 reverse dependency, is it fundamentally broken?
What if that number is 1? Where is the line?
At the end we're talking about the same workflow. I'm not saying it should
always be reverted, disagreeing
On Feb 25, 2015, at 3:12 AM, Cody Goodman codygman.consult...@gmail.com
wrote:
Using cabbage you only need to do 'cabbage; nix shell'. iirc, the sandboxes
were transparent.
This is correct. Linking into the local sandbox is a separate, optional step. I
wanted this as it let me
I now understand why we don't neccesarily want to use the with-packages
wrapper for building (Peter wrote a nice detailed response to the PR, if
anyone is interested in the reasons).
I am now wondering, why don't we make the `.env` shellHook the default
shellHook for the derivation too? I guess
Hi Benno,
Why don't we make the `.env` shellHook the default shellHook for the
derivation too?
Mateusz requested something like that earlier, and I created [1] to make
sure it's not forgotten. Basically, the idea was that an appropriate
shellHook allows you to work interactively in the
Hi,
I am getting a puzzling error when using Haskell NG on a freshly
installed system. My ~/.nixpkgs/config.nix is as follows:
{ ... }:
{
packageOverrides = super:
let
self = super.pkgs;
in {
hsEnv =
[sigh]...nevermind. I later realized that I was on the stable channel.
I see that the fix is on the unstable channel.
-- Daniel
On Wed, Feb 25, 2015 at 05:06:58PM -0700, Daniel J Beauregard wrote:
Hi,
I am getting a puzzling error when using Haskell NG on a freshly
installed system. My
Hi Mateusz,
With old Haskell setup we'd essentially have a shell.nix that was a bit like
let
pkgs = import nixpkgs {}
some_stuff = …;
in some_stuff.callPackage ./. {};
or some variation thereof. This allowed us to both nix-shell *and*
nix-build shell.nix out of the box. But
Hi Mateusz,
A related question: is there a way to generate a package list containing
exactly the versions of dependencies we require?
Say we have a package with cabal file
A == 1.0
B 2.0
C 0.5
but the latest Hackage has versions lower and higher c and that's what
is in
On 2015-02-24 at 23:24, Nikita Karetnikov nik...@karetnikov.org wrote:
A related question: is there a way to generate a package list containing
exactly the versions of dependencies we require?
I asked a similar question but about the cabal.config file some time
ago. Here's the response:
This almost certainly isn't ready for release, but I'd like to avoid
duplicating efforts if other people want to work on it...
Here is cabbage https://github.com/acowley/cabbage
It is a tool for doing the obvious thing: use the cabal solver to find
a build plan, then build the specific version
On Tue, Feb 24, 2015 at 4:29 PM, Peter Simons sim...@cryp.to wrote:
Hi guys,
many Python packages specify an attribute that disables build attempts
in certain packages sets, like this:
beaker = buildPythonPackage rec {
name = Beaker-1.6.4;
disabled = isPy3k;
[...]
Using cabbage you only need to do 'cabbage; nix shell'. iirc, the sandboxes
were transparent.
On Feb 24, 2015 11:57 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk
wrote:
On 02/25/2015 03:01 AM, Anthony Cowley wrote:
This almost certainly isn't ready for release, but I'd like to avoid
I've reverted the behavior in
https://github.com/NixOS/nixpkgs/commit/b653e3f6614fbe2664b1fd09d3baf5222b4de7f2
I'll take a look how to improve Hydra not to emit those messages in errors
tab.
On Wed, Feb 25, 2015 at 9:18 AM, Domen Kožar do...@dev.si wrote:
On Tue, Feb 24, 2015 at 4:29 PM,
Hi Mateusz,
Is there any way to recover old behaviour? I imagine if we can tell if
we're entering a nix-shell or
not then we can switch inside the expr and use .env when appropriate but
I don't know how to achieve this.
I have this PR: https://github.com/NixOS/nixpkgs/pull/6307 which would
16 matches
Mail list logo