[Nix-dev] Improving the Developer Experience in the Nix Community

[Shea Levy]

On Jun 27, 2012, at 12:09 PM, Michael Raskin <7c6f434c at mail.ru> wrote:

>>>> Well, it was just an example. My point was merely that it's not enough to point out a problem, whenever possible you should point out solutions and be willing to do the legwork necessary to implement them.
>>> The real problem is that for many things it does look like the problem
>>> is in value clash. There are people who want less lost patches and more
>>> committing whatever is not too disruptive and there are people who want
>>> more review, but they are objectively overloaded and so sometimes lose
>>> patches and, seemingly, consider rate of loss unfortunate but 
>>> acceptable.
>> You're talking a lot about value clash here. That's why I opened this thread, because we have people with different values but no one is really coming out and saying "this is what I want, this is why what's here now is bad". It's possible that when all is said and done there's no decision we can come to that will satisfy all parties, but we can't know until we know what the parties actually want. Please, if you have a vision for what the nix projects could be but aren't, share it. Otherwise it's highly unlikely that the nix you want to be will come into existence.
> 
> Well, I admire nix-the-packaging model. 
> 
> There are some things that I consider good with various evaluations
> in the community (some of them towards the end I never formulated 
> before - but now that I think of them...):
> 
> - There is a reasonable public place where I can see every package 
> expression used by any committer. So, if someone uses a git-head version
> of kernel, it would be nice to see what overrides were needed.
> 

Do you mean some sort of repository of local overrides? That might be nice, do you have any ideas about how that could be structured and where to put it?

> - There is a reasonable way for partial overrides of packages. That way
> when I look at a private overrided package I can see what the changes 
> relative to trunk are. Better yet if the changes are semantically 
> separated (where applicable). Currently it is partially enough - 
> changing preBuild usually means copying and editing. 
> 

Hm, I'm not sure I understand what you're going for here. Why do .override and overrideDerivation and friends not do enough for you?

> - There is a way to add support for marginal improvements to the default
> builder without full rebuild (why would we want to need stdenv-updates
> just to add xz support?)
> 

Agreed. Would you be interested in collaborating on a modular-stdenv (or something similar) branch to make this a reality?

> - The big packages used by many people are regularly and succesfully 
> built in a centralized way
> 

Isn't this just hydra?

> - On the level of Nix as a package manager, there is a way to roll back
> everything but GC
> 

What do you mean, exactly? You can roll back versions of nix, and if you use build.nix in the nix source tree you can build each component as its own derivation...

> - There is a simple way to declare something an acceptable substitute of
> something else.
> 

Do you mean substitute in the sense nix uses it, i.e. a way to realise a path without building it? Or something else?

> - There is a simple way to derive a version of package with dependency
> versions changed (for use with subsituters, mainly)
> 

Can you expand on this here? How would such a feature help?

> - There is a way to replace subsituted package with a "better" 
> substitution or native build
> 

I think I misunderstand what you mean by substitute in the above three issues :)

> I do not expect that any of them are widely shared (except existence of
> LibreOffice packages and rollback possibility, I hope), but as starting
> points..
> 
> Also, 
> 
> I value fast addition of new packages/new package versions above rarity
> of local breakages in the fastest-moving branch. I separately value not
> turning contributors away above avoidance of short glitches.
> 
> I think that having a partially-incompatible previous version (unless 
> there is a security issue) and a few bleeding-edge snapshots in addition
> to the default release in the main package set is more often beneficial 
> than harmful.
> 

Thanks for sharing your values there. Having it stated this explicitly makes it easier to find solutions that can find the right trade-off in our community. I've made a note of these for my upcoming work on policy documents.

~Shea