[Nix-dev] Package maintainer coordination problem and Nix

[Marc Weber]

Hi Mads,

> Yes, and it be by so much that it makes my hole scheme non-practical. 
Not sure. Some function can be implemented in C(++) making them faster.
That's even pretty easy.
I think nobody has tried yet?

Have a look at the mail "Subject: [Nix-dev] Nix interpreter optimisation".
I don't know the details very well. But it looks like even the nix
language interpreter can still be optimised much more.


> I imagined that this should be automated somehow. See reply to Peter.
> And people should be able to donated unused computer cycles.
That's kind of hard because compiling a package requires you downloading
all the dependencies first. I'm not sure whether you want to download
openoffice first before being able to test package X ? (This extreme
case illustrates the issue very well) On the other hand you can
implement this easily using the nix system.

> > But: If a package breaks for one of teh reasons you mentioned nix(os) is
> > the only distribution I know letting you do a git bisect to find the
> > "change" causing the failure easily. Of course this takes time. But
> > using debian or gentoo I don't even know where to start because
> > everything you have is emerge sync (which rsyncs all the package
> > descriptions).. Of course you can put this into git yourself but you
> > can't rollback easily if you broke the system.
> > 
> > Let's have a short look at systems which do what mentioned:
> > python: setup-tools (easy-install), eggs:
> >   quote: It's considered a bug if you require administrative priviledges
> > php: pear
> > ruby: rubyforge, ruby-gems
> > Eclipse and its plugin system (which provides its own rollback facility)
> > haskell + hackage..
> 

> Every programming community, creating their own solution.
don't think you can do better than the Eclipse community because it
really tries all possibilities to find a working setup. Nix doesn't do
that.

I much better
> like Nix - that is, create a solution that works for 95% of the
> developer population. And regular users too.
> 
> > 
> > And indeed they cause some headache to me because I'm not sure whether
> > I should package those stuff or just use it using easy-install and pear
> > update etc..
> > 
> > I worked on ruby recently. I solved it by adding a gem nix command which
> > creates a set of nix expression from those dynamic dependencies.
> > The result is that you can just do nix-env -iA sup and it works.
> > You can't do so on debian, can you?
> No way, I can do that with Debian. Get me right here, from what I have
> read, Nix is a huge step forward compared to Debian. And I do love
> Debian.
I like Debian because  it runs on all vservers out of the box. I still
don't have one running nixos perfectly..
Let me explain what I was thinking about:
About python eggs: http://pypi.python.org/simple/
Browse the list. It's huge. Same for the perl package system..
And in ten years the list of packages will even grow (maybe computer
speed increases more ?).. I think those packaging system has one nice
feature: They're kind of lazy: You only get the information you're
looking for. Most of them don't require you to get a complete list of
*all* packages available unless you do a search. Even gentoo has
introduced kind of overlays. (Could be done for nixpgks as well).
The question I raise is "do we actually want being able to install each
package which could be installed?". This means putting 
ruby-lib-{0.0, 0.3, 0.5, ..}
into the package system .. because you seggested that the user chooses
which one he wants and the system should figure out whether this can be
done and optionally find the solution wasting least disk space?
So probably this will evolve into a overlay like setup in the future
providing all packages for the group of users being interested in ruby,
php, haskell, .. only.

> I do not get this problem. Can you force Debian users to upgrade?
You acting as system admin can force updating a package. If you rebuild
the nixos system a user may still have package-X-very-old in his user
profile. You can't throw that away replacing it by a newer one. (Of
course you can find a way doing so..) But you get it.

> And I do not see as I problem either. My distribution telling me that it
> is very good idea to upgrade some package - fine. My distribution
> telling me that I am stupid if I do not upgrade - maybe OK.
Think of computer systems having 800 student login accounts.
At least 10% will never upgrade packages for various reasons (?)
So you'll end up having dozens of versions laying around in /nix/store
when you allow users to install personal packages (which is the strength
of nixos anyway?). But even this problem could be solved by sending
emails telling them to upgrade a package and calculating kind of quota
taking registered gc roots into account.
I like this idea. then you even can "share" your quota.

You can ping me on irc about nix(os) anytime. i'll try to help you then.

Yours
Marc Weber