theano: init at 0.8.1

[bcdarwin]

Built on Linux. See inline comments regarding testing.

No GPU support yet as I haven't built libgpuarray -- maybe the WIP tag should be added?

[teh]

IMO even without GPU support it's useful to get this in, and then to update in a second commit. I was going to have a construct like this:

  theano = callPackage ({ withGPU ? false }: buildPythonPackage rec {
    name = "Theano-0.8.1";
    ...
  }) {};

So people can pick the with-gpu version like this:

(theano.override { withGPU = true; }) 

My reasoning is that for libgpuarray to be useful it needs to pull in all of cuda, but theano is also useful without having the full cuda dependency pulled in.

[FRidh]

When I added numba I also did not add GPU support. We can indeed add that later.

There are quite some differences in dependencies between this expression and the one from @teh in #14790

[FRidh]

does it really need blas during runtime? Likely it compiles something against it during build time.

[bcdarwin]

I haven't tested without this, but I suspect it's necessary since compiling Theano itself is relatively trivial, but Theano itself compiles code at 'runtime'.

[FRidh]

Okay. Well, use numpy.blas instead. That way we can guarantee numpy, scipy, scikitlearn and also now theano use the same blas.

[teh]

I don't think you need pkgs.blas explicitly in here because it's already in numpy which is a hard dependency

[FRidh]

But blas is a buildInput to numpy, not a propagatedBuiltInput. When theano is build, blas would not be available, unless explicitly added.

[teh]

Right - for some reason theano works without for me, I think it might be picked up by scipy if I'm reading that correctly. Probably better to explicitly communicate the blas dependency in any case.

[FRidh]

I just saw I was wrong. blas is added as a propagatedBuildInput to both numpy and scipy. Therefore you get it for free in theano, and I don't think that is correct. I'll move blas to buildInput for both numpy and scipy (if it works, it should...).

Anyway, for here we need a (propagated) buildinput on numpy.blas. I would imagine theno would build a wrapper around blas, so just buildInput would be sufficient, but who knows, maybe it really does compile against blas during runtime.

edit: no we really need blas as propagatedBuildInput! silly me

[bcdarwin]

@teh I was going to do something similar as well, but haven't made time yet since that depends on libgpuarray being packaged.

@FRidh It could be merged now as-is, certainly.

[bcdarwin]

OK, I've switched to numpy.blas, and the tests still seem to work. Let me know if you'd prefer this commit squashed.

I guess we can revisit whether to change blas to a buildInput once the same is done for numpy and scipy (is there an issue/PR to refer to yet?).

[FRidh]

@bcdarwin I was wrong there. It is supposed to be a propagatedBuildInput because blas is needed during runtime because it is a shared library. I imagined for a moment they would statically compile it.

This looks good to me. Thanks.