I've finally gotten around to make that pull-request. You can find it here: https://github.com/NixOS/nixpkgs/pull/3056
Thanks for your help! On 15 June 2014 22:11, Mateusz Kowalczyk <[email protected]> wrote: > On 06/15/2014 09:09 PM, Andreas Herrmann wrote: > > Thanks for your detailed answer. > > > > On 15 June 2014 02:28, Mateusz Kowalczyk <[email protected]> > wrote: > > > >> On 06/14/2014 11:17 PM, Andreas Herrmann wrote: > >>> A) Is there some kind of test suite that I need to run on the > expressions > >>> before I can send a pull request? (I can build and use them...) > >> > >> Simply make sure it builds and runs on top of the current master. For > >> Python, check multiple Python versions. nix-build can help you build the > >> packages. > >> > > > > Okay, it runs on all python versions except pypy. Which is to be > expected. > > However, the pypy branch seems to be somewhat broken. The build failed at > > setuptools long before it reached my package. > > > > > >>> C2) The test-suite of pytables takes quite some time and has a number > of > >> > >> failures of the "not-implemented" type. Is it worth including that > >>> test-suite or should I just leave that one out? > >> > >> I would include any steps necessary to run the tests but after ensuring > >> that the failures aren't NixOS/nix specific, I'd set doCheck = false: > >> this makes it easier for you or someone else to turn on the tests on any > >> future, fixed versions. Make sure to let the maintainer know that there > >> are failing tests. > >> > > > > I dug a little deeper and found that the problem was actually rooted in > the > > hdf5 package. pytables needs it to be built with zlib. I put that in, and > > also fixed the szip package. However, both could be called optional > > dependencies on hdf5. Do you know, how I can make pytables depend on hdf5 > > with a certain set of parameters? Or are these things handled through > > comments and documentation? > > > > To be more explicit: say hdf5 has the parameters `{ stdenv, fetchurl, > zlib > > ? null, szip ? null }`. How can I make pytables depend on hdf5 in such a > > way, that it requires `zlib != null`, but doesn't care about `szip`? > > I can't say for sure but I'd imagine you'd simply override it as usual. > Say you have pytables at > development/python-modules/pytables.default.nix: your entry to > python-modules.nix could look like > > pytables = callPackage ../development/python-modules/pytables { > hdf5 = pkgs.hdf5.override { zlib = pkgs.zlib; }; > }; > > python-modules.nix seems to have a whole section for packages defined > elsewhere so perhaps look at that bit. The style there seems to be using > import rather than callPackage however. I imagine it would look similar > to the below: > > pytables = import ../development/python-modules/pytables { > inherit (pkgs) stdenv fetchurl whateverotherdeps; > inherit python numbexpr whateverotherpythondeps; > hdf5 = pkgs.hdf5.override { zlib = pkgs.zlib; }; > }; > > Although this is a mere guess: I have not tested this. > > If you have decided to put the package definition in all-packages.nix > then the first way should work fine, just drop pkgs. prefixes. > > > > >>> D1) Pandas works without pytables. However, without it, it cannot > >>> import/export hdf5 archives. Should I add PyTables as a dependency to > >>> Pandas, or should every user individually add both to his environment > if > >> he > >>> needs both? Or is there a way to make it an optional dependency? > >> > >> Optional dependencies are possible but I am unsure how they are done for > >> Python packages. While I don't know how to specify such optional > >> dependencies in python-packages.nix, you can simply create a > >> nix-expression outside of it. See pkgs/games/anki/default.nix for an > >> example of a Python package with optional dependencies. Provide a > >> sensible default because only the default way will be built by Hydra. > >> > >> If you need Hydra to build the package in more ways then you should make > >> two separate entries in all-packages.nix with the different flag setups > >> but if there's only one common case then one should suffice. > >> > > > > I went to the pandas documentation and found out that they actually list > > about a dozen optional dependencies. I came to the conclusion, that it is > > probably easiest to not list them at all, since in the python world such > a > > dependency doesn't require re-building, but just availability in the > module > > search path. No reason to multiply the number of binaries if they end up > > all being the same. > > > > You're correct that there's probably no reason to list them all but if > the package ends up with different features depending on what's > available at build time then perhaps you should allow the user of the > package to toggle these dependencies on, even if they're off by default. > > -- > Mateusz K. > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
