New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pythonPackages.fipy: init at 3.3 #65035
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to rebase the commits? At the moment the commit for fipy is before its dependency pyamg. Also within the commits there is another python module added and removed again. Not sure this matters in the long run but would be nice to clean up.
, fetchPypi | ||
, numpy | ||
, setuptools | ||
, blas |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason this can't be parsed in as openblas to avoid having to pass in { blas = pkgs.openblas }
in the callPackage statement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is so that in the future someone could provide mkl, atlas, blas instead. We do a similar thing with numpy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fair enough
pkgs/top-level/python-packages.nix
Outdated
@@ -4044,6 +4046,10 @@ in { | |||
|
|||
pyspread = callPackage ../development/python-modules/pyspread { }; | |||
|
|||
pysparse = callPackage ../development/python-modules/pysparse { | |||
blas = pkgs.openblas; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not familiar with this package, but i would at the very least keep the aliasing consistent
blas = pkgs.openblas; | |
openblas = pkgs.openblas; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mentioned this in a previous comment. What if we would like to use mkl in the future? blas is more consistent. (also atlas and blas are options as well)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can have additional flags such as:
, pkgs
, withBlas ? false
, withMKL ? false
....
and then later on:
buildInputs = [
...
] ++ lib.optional withBlas pkgs.openblas
++ lib.optional withMKL pkgs.mkl;
but, you can set them to be true when calling the package
fipy = callPackage .... { withMKL = true; }
really just depends on how to you want to structure injecting those options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/python-modules/tensorflow/default.nix
is a good example as it conditionally enables CudaSupport. And does an "intelligent" look-up of what instruction sets are available for a given architecture.
I'm not sure if you're trying to set a framework to use, or choose between many.
@wd15 please change the title of the PR to |
PR builds for me Result of 7 package were build:
|
I would name the maintainer commit "Add wd15 to maintainers.nix" and put it before any of the others |
I think it's not usual to merge master into your branch either |
0c426d1
to
1eb6142
Compare
|
@alexarice: commits should be clean now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good apart from darwin issues
@wd15 remove the [WIP] tag. Looks like this PR ready to go (aside from the darwin issue). If you want you could set |
|
||
propagatedBuildInputs = [ | ||
numpy | ||
blas |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it need to link to the same blas as is used by numpy? There is the numpy.blas
attribute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, yes it does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now using numpy.blas
@smaret, thanks for your previous test. I've updated the PySparse build to a more recent version, which built for me on Darwin. Could you try again? |
I feel like that brokepip.patch is a little heavy at 22k lines... |
@jonringer, I can fix that. I should just apply the patch and use the GitHub repository. |
@jonringer, large patch is gone |
PR builds on Darwin for |
Result of 7 package were build:
nix review passes! LGTM |
Motivation for this change
Add the FiPy PDE solver, see https://www.ctcms.nist.gov/fipy/
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nix-review --run "nix-review wip"
./result/bin/
)nix path-info -S
before and after)