[Nix-dev] Fixing module arguments (PROPOSAL MAY BREAK EXISTING NIXOS CONFIGS, PLEASE READ)

[Thomas Bereknyei]

I would agree. NixOS is known to be experimental and breaking changes
should be ok with any users. And if they have a problem with it, rollback!

If this simplifies the module arguments then it may be worth it, because it
still confuses me, so I guess others may benefit as well.

That being said, I am not familiar with the second order effects.

Tom
Shea Levy <shea at shealevy.com> writes:
Hi Shea,

> The Easy Solution
> -----------------

In my opinion the whole project is young enough that we are not yet at a
stage where we have to live with things being difficult to work with. I
think most people who are using NixOS in real deployments are aware of
the fact that they still have to interact with the Nix community, and be
willing to change their deployments as configuration changes.

I may be putting words in other's mouths, but that is certainly how I
feel.

> The Conservative Solution
> -------------------------
> [..]
>
> The Moderate Solution
> ---------------------

Following on from my earlier feeling - if we're going to make massive
changes, I'd prefer to keep that window as small as possible. If that
means making a huge change in one pass, then that is what I would
prefer. This means I only have to understand one type of change, and I
only have to fiddle with my deployment configurations once.

The more times I have to change things, the more likely I am to be
confused as to what exactly is going on, and increases the chance that
I'll screw something up. So...

> The Radical Solution
> --------------------

*If* you're convinced that there is a problem in the module system and
that this is the best solution, then I would not be against this type of
change. The argument about having to do a partial evaluation with a
dummy pkgs strongly suggests the model we have now is not the correct
one, and I'd be willing to pay the cost (be that changing my
configurations or helping out with changes in nixpkgs itself) to correct
that.

That said, a few concrete examples would really help clarify the
situtation for me, as I don't think I've entirely understood even the
problem itself.

Is it possible for you to share some of the nixops work you've been
doing, with how it looks now and what the pain points are? Ideally,
seeing how these pain points are solved by some of these solutions would
also be extremely useful - especially as the solutions tend towards the
more radical changes.

- ocharles
_______________________________________________
nix-dev mailing list
nix-dev at lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140219/50da713a/attachment.html