> 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 _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
