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
