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

python37Packages.tensorflow-bin: 1.14.0 -> 2.1.0 #81278

Merged
merged 4 commits into from Mar 2, 2020

Conversation

cdepillabout
Copy link
Member

@cdepillabout cdepillabout commented Feb 28, 2020

Motivation for this change

This bumps python37Packages.tensorflow-bin to version 2.1.0.

It also bumps some of the dependencies of tensorflow-bin to the required versions:

  • tensorflow-tensorboard: 1.15.0 -> 2.1.0
  • tensorflow-estimator: 1.15.1 -> 2.1.0

With this PR, tensorflow-bin builds correctly, and appears to be able to be used correctly with python37Packages.

I've tested it with the following simple python script (from https://www.tensorflow.org/tutorials/quickstart/beginner):

from __future__ import absolute_import, division, print_function, unicode_literals
import tensorflow as tf

mnist = tf.keras.datasets.mnist
(x_train, y_train), (x_test, y_test) = mnist.load_data()
x_train, x_test = x_train / 255.0, x_test / 255.0

model = tf.keras.models.Sequential([
  tf.keras.layers.Flatten(input_shape=(28, 28)),
  tf.keras.layers.Dense(128, activation='relu'),
  tf.keras.layers.Dropout(0.2),
  tf.keras.layers.Dense(10)
])
loss_fn = tf.keras.losses.SparseCategoricalCrossentropy(from_logits=True)
model.compile(optimizer='adam', loss=loss_fn, metrics=['accuracy'])
model.fit(x_train, y_train, epochs=5)
model.evaluate(x_test,  y_test, verbose=2)

I've only tested this on Linux without CUDA. I would appreciate if someone could try this out on Mac or with CUDA enabled.

I'm a beginner with both Tensorflow and Python, so please let me know if I am doing anything weird here.

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.

@cdepillabout
Copy link
Member Author

cdepillabout commented Feb 28, 2020

Here are two related PRs:

@cdepillabout
Copy link
Member Author

cdepillabout commented Feb 28, 2020

I'm currently in the process of testing the following:

  • Linux, non-cuda:
    • python36Packages.tensorflow-bin (I've confirmed this works)
    • python35Packages.tensorflow-bin (this fails because the tests fail for opt_einsum-3.1.0, which is a direct dependency of tensorflow-bin. As far as I can tell, opt_einsum-3.1.0 doesn't support python35. I created an issue upstream: modify python_requires in setup.py to require python 3.6+ dgasmith/opt_einsum#126)
    • python27Packages.tensorflow-bin (this fails while running the tests for google-auth-oauthlib-0.4.1, which is a dependency of tensorflow-tensorboard, which is used by tensorflow-bin)

@cdepillabout
Copy link
Member Author

@GrahamcOfBorg build python37Packages.tensorflow-bin python36Packages.tensorflow-bin python35Packages.tensorflow-bin python27Packages.tensorflow-bin

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.

Did not test this but the change looks good to me.

@cdepillabout
Copy link
Member Author

I forgot to update the hash for tensorflow-tensorboard for python27, so I just updated it and force-pushed.

@veprbl
Copy link
Member

veprbl commented Feb 28, 2020

Shouldn't update to pythonPackages.tensorflow-tensorboard and pythonPackages.tensorflow-estimator break the pythonPackages.tensorflow unless we don't bump it as well?

@cdepillabout
Copy link
Member Author

cdepillabout commented Feb 28, 2020

@veprbl I was under the impression that pythonPackages.tensorflow was already broken.

When I try to build it on master, I get the following message:

$ nix-build -A python37Packages.tensorflow
error: Package ‘openssl-1.0.2u’ in /home/illabout/git/nixpkgs/pkgs/development/libraries/openssl/default.nix:130 is marked as insecure, refusing to evaluate.

Known issues:
 - Support for OpenSSL 1.0.2 ended with 2019.

You can install it anyway by whitelisting this package, using the
following methods:
...

I don't think this should hold back updating tensorflow-bin.

Although, it would also be great to get an up-to-date version of pythonPackages.tensorflow. It is unfortunately out-of-scope for this PR though.

@jonringer
Copy link
Contributor

@veprbl I was under the impression that pythonPackages.tensorflow was already broken.

This is my understanding as well, I'm fine with surpassing a broken build.

@tbenst
Copy link
Contributor

tbenst commented Mar 1, 2020

tensorflow is fixed pending merge of two PRs: #80379 (comment).

tensorflow 2 is sadly not fully backward-compatible with tensorflow 1, and there are a number of libraries / applications that are not moving. I’d love to see both versions in nixpkgs.

@FRidh FRidh merged commit 9e8dea7 into NixOS:master Mar 2, 2020
@cdepillabout cdepillabout deleted the tensorflow-bin-2.1.0 branch March 2, 2020 08:38
@andir
Copy link
Member

andir commented Mar 2, 2020

This now broke the non-bin package of tensorflow. Some of us were using it but others (like me) were trying to unbreak the edge-cases I am hitting.

TF 1.15 might have been broken in a few ways. With this PR merged we now need to unbreak even more.. I guess I'll just go about adding a second version of TF estimator for the older TF 1.15.

@FRidh
Copy link
Member

FRidh commented Mar 2, 2020

Those that need tensorflow and related packages need to cooperate a bit more, because with all these different PR's touching it, it is hard to follow.

@timokau
Copy link
Member

timokau commented Mar 2, 2020

Since there seem to be many people who are very interested in keeping it working, it would be nice if some of them could add themselves as additional maintainers. Due to time constraints maintaining it isn't a very high priority for me personally right now.

@cdepillabout
Copy link
Member Author

cdepillabout commented Mar 3, 2020

@andir Sorry for breaking the other tensorflow with this.

Could we merge in #70910 (after possibly updating it to 2.1.0)? That way we wouldn't have to carry around multiple versions of tensorflow-estimator (which I thought was strictly not allowed in the python package set).

@Zhen-hao
Copy link

Zhen-hao commented Apr 4, 2020

hi, what is the new tensorflowWithCuda for 2.1?
Is it built in tensorflow_2?

@Ericson2314
Copy link
Member

Look at the old ones definition? All I know of is a cudaSupport flag on 1.x and 2.x.

@Zhen-hao
Copy link

Zhen-hao commented Apr 4, 2020

you are right.

  tensorflowWithCuda = self.tensorflow.override {
    cudaSupport = true;
  };

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

9 participants