[Nix-dev] Re: Python packages in peril

[Marc Weber]

> I think these tests, if you want them, should be in the package in 
> question, e.g., by having some "assert" check in pycairo.
The long time goal is generating those expressions from package
databases.

Then it may be nice to separate this information telling about not
building packages from the package description.
That's what I've been doing for Ruby and Haskell and it works quite
nice.

> The "all" attribute seems unnecessary, since you can also do "nix-build 
> -A pythonPackages".
the all is used to remove the buildPythonPackage attr which caused
trouble.

I didn't think about this as being a big change. If I broke
references in documentation we should discuss whether I should rename
the file back to python-packages or whether we should modify the
documentation, so that it points to python2-packages now.

Whether everything is located in development or not - I don't care.

All I want is being able to determine which packages build using which
python version fast. Keeping a global list is the only way to do so if
you want to replace the implementation providing the package list later.

I'm going to do that as soon as I can take time.

No doubt I will cause disruption in the future again. If you dislike it
too much there are 3 ways:
a) force me to use a marc-weber branch for comitting only
b) rename trunk to "stable", ask everyone to commit to different
  branches. Setup a weekly meeting (can be done by email) to discuss which
  changes to merge into "stable" or what to change before merging into
  "stable". Code quality will increase.
  The buildfarm could be setup to build all those -dev branches.
  Failures which may occur some days after comitting will be caught.
b') switch to git and use b) style of development.
c) cancel my SVN account

I'd prefer b') because it would be fastest for everyone. Eg github
nowadays even supports checking out and comitting using subversion !

github nowadays even lets you comment commits. So when deciding which
commits to move into a "stable" branch can be done fast because
everybody has a chance to comment them.

I personally consider a broken trunk in nixpkgs being a result of the
current development cycle I'm forced to use.

The only true fix is dropping trunk, adding a "stable" or release
branch. It is not feasable asking every comitter to test all variations
on all platforms (x86_64, i686, arm, Windows..)

So I vote for b'). If that can't be done I'd vote for b'). However this
would mean that I have to spend time on SVN rather than updating
packages.

Of course this is only my humbled opinion - You may think in a different
way about this.

Marc Weber