python.pkgs.{tensorflow,tensorflow-estimator,tensorflow-tensorboard}-2: Init at 2.0.0#83518
Conversation
16bb15f to
94399fb
Compare
There was a problem hiding this comment.
Might be better to use the builtin configurePhase, and just set the flags (dontAddPrefix, ...) to disable the incorrect arguments
There was a problem hiding this comment.
This means you want to extend RPATH, not link directly here. I think -rpath ${cuda}/lib -rpath ${cudatoolkit}/lib should accomplish this.
There was a problem hiding this comment.
(This may be something we need in a setup hook for cuda)
pkgs/top-level/python-packages.nix
Outdated
There was a problem hiding this comment.
maybe there is some reason for packaging every single cudatoolkit version, but perhaps we should just rely on the top level one here, instead of a specific version
There was a problem hiding this comment.
I guess this was already here though, so may be okay to leave as is.
There was a problem hiding this comment.
If possible, I would much prefer a patch that we can send upstream
FRidh
left a comment
There was a problem hiding this comment.
I don't think the versioned packages aside from tensorflow should be exposed. Instead, offer a single attribute for each package (tensorflow-estimator, tensorflow-tensorboard) that will depend on tensorflow attribute. Using a different version of tensorflow (and dependents) is a matter of overriding the package set to select the tensorflow version.
pkgs/development/python-modules/tensorflow-estimator/2/default.nix
Outdated
Show resolved
Hide resolved
pkgs/development/python-modules/tensorflow-tensorboard/2/default.nix
Outdated
Show resolved
Hide resolved
94399fb to
32e6f54
Compare
|
Ah so the defaults between 1 and 2 are already inconsistent between I did fix the unneeded 3rd version, however. |
|
I think tensorflow 1 build was broken for a good while, so some things were let in that probably shouldn't have. |
|
OK I'll just change it then |
|
I'm not super familiar with the tensorflow universe, but is there a reason why this is packaging tensorflow-2.0 instead of 2.1? |
That's a very good question, because we typically do not keep older versions. 1.15 was kept as an exception. |
|
I think its fine to get this merged first, then update to 2.1.0. This is a great improvement either way. If we decide to go straight to 2.1.0, I'd still like to preserve the 2.0.0 commit in history in case someone needs that particular version or we need to bisect an issue later. |
|
I am working locally to switch to 2.1, since master is already partly (!!) ungraded to 2.1.
That was my thought too, before I had realized it was too late for the clean transition. |
Needed for Tensorflow 2.1
7f3b47a to
1fa3105
Compare
|
OK fixed @FRidh's concerns, and Matt's can be done later because they apply equally to the existing packages. The ofborg failure is because of a master issue. |
Motivation for this change
Major breaking change from 1.x, so treating keeping both versions for now.
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)