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] Add requirements.txt and test #5408

Merged
merged 3 commits into from
Jul 7, 2020

Conversation

stwunsch
Copy link
Contributor

@stwunsch stwunsch commented Apr 21, 2020

Proposal to add a requirements.txt file and a corresponding test checking the dependencies also by the version requirement.

The test throws an error for each dependency seperately due to the SubTest. A single exception looks like this:

3: pkg_resources.VersionConflict: (xgboost 0.80 (/home/stefan/.local/lib/python3.8/site-packages), Requirement.parse('xgboost>=0.81'))

@eguiraud @Axel-Naumann @etejedor @oshadura Ping :)

@stwunsch
Copy link
Contributor Author

@oshadura How can I get the path to the requirements.txt in the test? ROOTSYS does not really help because it points to the build dir, I would need the path to the source dir.

@vepadulano
Copy link
Member

vepadulano commented Apr 21, 2020

@oshadura How can I get the path to the requirements.txt in the test? ROOTSYS does not really help because it points to the build dir, I would need the path to the source dir.

Supposing the test is under "path/to/root/bindings/pyroot_experimental/pythonizations/test/" you could do:

import os
abspath = os.path.abspath(__file__) # path/to/root/bindings/pyroot_experimental/pythonizations/test/test.py
reqpath = os.path.join(abspath.partition("bindings/")[0], "requirements.txt")  # path/to/root/requirements.txt

with open(reqpath) as f:
...

Though I wonder whether the requirements.txt file would be better suited under the bindings folder since it's python related?

@stwunsch
Copy link
Contributor Author

I didn't want to do too much path magic, too prone to break ;) The location of the requirements.txt file is also a good question. @axel @oshadura ? People would expect it in the root folder though.

@vepadulano
Copy link
Member

I get what you mean, but in this case I don't think the location of the bindings/ folder will change anytime relative to the home root folder right? Otherwise, a new ROOTHOME variable could be set along with ROOTSYS ?

@stwunsch
Copy link
Contributor Author

Do we run the tests always from the source directory? I'm not 100% sure about this.

@vepadulano
Copy link
Member

I believe that os.path.abspath always returns the absolute path starting from the / folder of the machine, irrespective of the folder from where the test is running. At least on linux, not sure about windows

@stwunsch stwunsch requested a review from eguiraud April 22, 2020 07:00
@vepadulano
Copy link
Member

There is also root-config --srcdir that actually returns the path to the main root directory, it could be called with subprocess in python

@stwunsch
Copy link
Contributor Author

Nice! That's actually a quite nice solution, and could be viable for the tests. Just hope you don't move the source dir ;) Could be a start!

@eguiraud
Copy link
Member

eguiraud commented Apr 22, 2020

Hi,
isn't it enough (and more similar to what users would experience) to run pip check? It could even be done at ROOT configuration time if -Dpython=ON

@stwunsch
Copy link
Contributor Author

@eguiraud Good question! I don't know whether we want to enforce this a configuration time. Would make sense, tbh, though this would enforce much more stricter requirements than the ones we have now.

@oshadura
Copy link
Contributor

I didn't want to do too much path magic, too prone to break ;) The location of the requirements.txt file is also a good question. @axel @oshadura ? People would expect it in the root folder though.

About location, totally make sense!

@oshadura
Copy link
Contributor

Hi,
isn't it enough (and more similar to what users would experience) to run pip check? It could even be done at ROOT configuration time if -Dpython=ON

We don't have this option anymore :) Now it is "pyroot"...

@oshadura
Copy link
Contributor

Why not to add in "dev" option?

@stwunsch
Copy link
Contributor Author

So I think what we agreed on on Mattermost: We want the thingy, but no checks at configure time (because it's not a build time dependency). We still have to iterate how exactly we want to check at test time the dependencies, but I think at a first shot, the current impl is good enough. Feel free to argue :)

@stwunsch stwunsch changed the title [NFC][Python] Add requirements.txt and test [Python] Add requirements.txt and test Apr 23, 2020
@stwunsch
Copy link
Contributor Author

@phsft-bot build

@phsft-bot
Copy link
Collaborator

Starting build on ROOT-debian10-i386/cxx14, ROOT-performance-centos7-multicore/default, ROOT-fedora29/python3, ROOT-fedora30/cxx14, ROOT-fedora31/noimt, ROOT-ubuntu16/nortcxxmod, mac1015/cxx17, windows10/cxx14
How to customize builds

1 similar comment
@phsft-bot
Copy link
Collaborator

Starting build on ROOT-debian10-i386/cxx14, ROOT-performance-centos7-multicore/default, ROOT-fedora29/python3, ROOT-fedora30/cxx14, ROOT-fedora31/noimt, ROOT-ubuntu16/nortcxxmod, mac1015/cxx17, windows10/cxx14
How to customize builds

@phsft-bot
Copy link
Collaborator

Build failed on ROOT-fedora31/noimt.
Running on root-fedora-31-1.cern.ch:/build/workspace/root-pullrequests-build
See cdash.
See console output.

Failing tests:

@phsft-bot
Copy link
Collaborator

Build failed on mac1015/cxx17.
Running on macphsft18.dyndns.cern.ch:/Users/sftnight/build/jenkins/workspace/root-pullrequests-build
See cdash.
See console output.

Failing tests:

@stwunsch
Copy link
Contributor Author

stwunsch commented Jul 7, 2020

But it's a good question, because we do not depend on pandas like on jupyter or numba. we just support to push data to it and test a specific interface of pandas.

@phsft-bot
Copy link
Collaborator

Starting build on ROOT-debian10-i386/cxx14, ROOT-performance-centos7-multicore/default, ROOT-fedora30/cxx14, ROOT-fedora31/noimt, ROOT-ubuntu16/nortcxxmod, mac1014/python3, mac1015/cxx17, windows10/cxx14
How to customize builds

@phsft-bot
Copy link
Collaborator

Build failed on ROOT-debian10-i386/cxx14.
Running on pcepsft10.dyndns.cern.ch:/build/workspace/root-pullrequests-build
See cdash.
See console output.

Failing tests:

@stwunsch
Copy link
Contributor Author

stwunsch commented Jul 7, 2020

Here an example from the failure above how the diagnostics look like:

Full path to requirements.txt: /home/sftnight/build/workspace/root-pullrequests-build/root/requirements.txt
Details about not matched dependencies:
 - The 'numba>=0.47.0' distribution was not found and is required by the application

@stwunsch
Copy link
Contributor Author

stwunsch commented Jul 7, 2020

We should merge root-project/rootspi#81 first and retry the PR build (afaik rootspi is getting fetched again on each build).

@stwunsch
Copy link
Contributor Author

stwunsch commented Jul 7, 2020

@phsft-bot build

@phsft-bot
Copy link
Collaborator

Starting build on ROOT-debian10-i386/cxx14, ROOT-performance-centos7-multicore/default, ROOT-fedora30/cxx14, ROOT-fedora31/noimt, ROOT-ubuntu16/nortcxxmod, mac1014/python3, mac1015/cxx17, windows10/cxx14
How to customize builds

@stwunsch
Copy link
Contributor Author

stwunsch commented Jul 7, 2020

@eguiraud I would say the CI is happy ;)

@stwunsch
Copy link
Contributor Author

stwunsch commented Jul 7, 2020

You think it's good to go like this? It does not have yet all dependencies, e.g., the ones for TMVA experimental are missing. Though we should could have with this a first run through the nightlies and fix failures in our infrastructure (missing packages, version mismatches, ...).

@stwunsch
Copy link
Contributor Author

stwunsch commented Jul 7, 2020

I think there should be little failures since we switch already long ago to the "just fail the test" mode. But you never know :)

@eguiraud
Copy link
Member

eguiraud commented Jul 7, 2020

I think there should be little failures since we switch already long ago to the "just fail the test" mode. But you never know :)

There is a ton of tutorials that would fail that currently do not run, see #5938 . But I don't think this PR interferes with that, right @hageboeck ?

@hageboeck
Copy link
Member

hageboeck commented Jul 7, 2020

I think there should be little failures since we switch already long ago to the "just fail the test" mode. But you never know :)

There is a ton of tutorials that would fail that currently do not run, see #5938 . But I don't think this PR interferes with that, right @hageboeck ?

They are kind of doing the same thing, but #5938 is dumb. It only checks if it can import <package> at all, and then runs the tutorial or fails all that need e.g. numpy. It doesn't care for versions. I guess I can rewrite the ${PYTHON_EXECUTABLE_DevMain} -c "import <package>" from the other PR to simply use the test from this PR.

For this, however, it would be nice if you could ask for specific packages. So the thing would look up numba in the requirements, and test if the correct version is installed to run a tutorial or test.

This way, we would also get a cross-check that dependencies of tests/tutorials are actually in requirements.txt.

Copy link
Member

@eguiraud eguiraud left a comment

Choose a reason for hiding this comment

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

Alright, I think this can go in and together with the labels that #5938 adds it should address what we agreed upon at yesterday's meeting

@hageboeck
Copy link
Member

I edited my previous comment, maybe check again.

@hageboeck
Copy link
Member

Also, we might be missing numpy, keras, xgboost in the requirements.

@hageboeck
Copy link
Member

And pandas.

@eguiraud
Copy link
Member

eguiraud commented Jul 7, 2020

This PR solves the problem of documenting our python requirements and adding a test that checks if we satisfy them at runtime.

#5938 solves three main problems (plus a couple smaller things): a bug in an RDF tutorial, a bug in the vetoing of tutorials, and it adds a nice-to-have, namely having a single test fail that's clearly called "test-if-numba-is-there" rather than having all numba tests red.

If what I said above is in the ballpark of correct, there is no conflict with #5938. so I still think this PR could go in modulo the missing requirements -- consider my approval conditional to agreeing on what should go in requirements.txt (i'll stay out of the discussion about whether pandas should be in there or not :D)

@stwunsch
Copy link
Contributor Author

stwunsch commented Jul 7, 2020

Alrighty, I'll add sklearn, numpy, xgboost and keras one by one and check against the PR builds the status on the nodes. This will cause havoc for a few iterations 😬

@hageboeck
Copy link
Member

Alrighty, I'll add sklearn, numpy, xgboost and keras one by one and check against the PR builds the status on the nodes. This will cause havoc for a few iterations 😬

I guess that's what Philippe meant. You can merge as-is, and I'll adapt the other PR accordingly. Let's maybe agree that the ML things are not hard requirements.

@phsft-bot
Copy link
Collaborator

Starting build on ROOT-debian10-i386/cxx14, ROOT-performance-centos7-multicore/default, ROOT-fedora30/cxx14, ROOT-fedora31/noimt, ROOT-ubuntu16/nortcxxmod, mac1014/python3, mac1015/cxx17, windows10/cxx14
How to customize builds

@stwunsch
Copy link
Contributor Author

stwunsch commented Jul 7, 2020

Alrighty, I'll add sklearn, numpy, xgboost and keras one by one and check against the PR builds the status on the nodes. This will cause havoc for a few iterations grimacing

I guess that's what Philippe meant. You can merge as-is, and I'll adapt the other PR accordingly. Let's maybe agree that the ML things are not hard requirements.

For me it means that we have actually no idea whether some things work or not ;) I've added numpy and that's good for now. I think it's overkill to add the TMVA deps now, because I also don't know exactly what the required versions are.

@stwunsch
Copy link
Contributor Author

stwunsch commented Jul 7, 2020

There's now https://sft.its.cern.ch/jira/browse/ROOT-10909 to track this issue.

@phsft-bot
Copy link
Collaborator

Build failed on ROOT-fedora31/noimt.
Running on root-fedora-31-2.cern.ch:/home/sftnight/build/workspace/root-pullrequests-build
See cdash.
See console output.

Failing tests:

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

6 participants