Skip to content
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

python.pkgs.{tensorflow,tensorflow-estimator,tensorflow-tensorboard}-2: Init at 2.0.0 #83518

Merged
merged 5 commits into from Mar 30, 2020

Conversation

Ericson2314
Copy link
Member

Motivation for this change

Major breaking change from 1.x, so treating keeping both versions for now.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.


configurePhase = ''
runHook preConfigure
./configure
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be better to use the builtin configurePhase, and just set the flags (dontAddPrefix, ...) to disable the incorrect arguments

runHook postConfigure
'';

# FIXME: Tensorflow uses dlopen() for CUDA libraries.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This means you want to extend RPATH, not link directly here. I think -rpath ${cuda}/lib -rpath ${cudatoolkit}/lib should accomplish this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(This may be something we need in a setup hook for cuda)

inherit (pkgs.darwin.apple_sdk.frameworks) Foundation Security;
};

tensorflow-build-2 = callPackage ../development/python-modules/tensorflow/2 {
cudaSupport = pkgs.config.cudaSupport or false;
inherit (pkgs.linuxPackages) nvidia_x11;
cudatoolkit = pkgs.cudatoolkit_10;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this was already here though, so may be okay to leave as is.

let
withTensorboard = pythonOlder "3.6";

cudatoolkit_joined = symlinkJoin {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If possible, I would much prefer a patch that we can send upstream

];
};

cudatoolkit_cc_joined = symlinkJoin {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for this as well

Copy link
Member

@FRidh FRidh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/top-level/python-packages.nix Show resolved Hide resolved
pkgs/top-level/python-packages.nix Outdated Show resolved Hide resolved
@Ericson2314
Copy link
Member Author

Ericson2314 commented Mar 27, 2020

Ah so the defaults between 1 and 2 are already inconsistent between tensorflow and tensorflow-evaluator. I think that means the automatic-default version thing to do will be hard. I rather do it later with a round of breaking changes, if that is alright. It is also complicated by some tensorflow-* using tensorflow, and others being used by tensorflow.

I did fix the unneeded 3rd version, however.

@jonringer
Copy link
Contributor

I think tensorflow 1 build was broken for a good while, so some things were let in that probably shouldn't have.

@Ericson2314
Copy link
Member Author

OK I'll just change it then

@cdepillabout
Copy link
Member

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?

cdepillabout and others added 2 commits March 28, 2020 03:05
TF 1.15 still needs an older version of the tensorflow-estimator
package.

(cherry picked from commit c539f93)
@FRidh
Copy link
Member

FRidh commented Mar 28, 2020

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.

@timokau
Copy link
Member

timokau commented Mar 28, 2020

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.

@Ericson2314
Copy link
Member Author

I am working locally to switch to 2.1, since master is already partly (!!) ungraded to 2.1.

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.

That was my thought too, before I had realized it was too late for the clean transition.

Ericson2314 and others added 3 commits March 30, 2020 04:30
Needed for Tensorflow 2.1
Major breaking change from 1.x, so treating keeping both versions for now.

(adapted from 33f11be)
(adapted from 9e8dea7)
@Ericson2314
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants