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

Consistency with Rpy 1 and NumPy packages and tools, e.g. linear_regression #415

Open
blankenberg opened this issue Nov 22, 2016 · 4 comments
Labels

Comments

@blankenberg
Copy link
Member

These tools and dependency chains are broken. But will work if you have numpy 1.7 available locally. Detailed analysis follows.

Rpy requires NumPy, but the current version of rpy 1.0.3 in the toolshed (https://toolshed.g2.bx.psu.edu/repos/devteam/package_rpy_1_0_3/file/82170c94ca7c/tool_dependencies.xml https://toolshed.g2.bx.psu.edu/view/devteam/package_rpy_1_0_3/82170c94ca7c) does not have a repository dependency defined.

However, the current version in github, https://github.com/galaxyproject/tools-devteam/blob/fbc219afb27b57b7a7aabbf2936439273753664e/packages/package_rpy_1_0_3/tool_dependencies.xml, has a dependency on numpy 1.9, added in fbc219a.

But I don't think we can or should 'just update' this package in the toolshed, due to inconsistencies when digging into tools.

The linear_regression tool (https://github.com/galaxyproject/tools-devteam/tree/master/tools/linear_regression https://toolshed.g2.bx.psu.edu/view/devteam/linear_regression/cf431604ec3e) has dependencies on rpy 1.0.3, R 2.11.0, and numpy 1.7.

This causes an error with linear_regression (and possibly other tools), when Rpy is built against NumPy 1.9, but given NumPy 1.7:

RuntimeError: module compiled against API version 9 but this version of numpy is 7

I was able to hack the Rpy 1.0.3 package locally to get these tools to work, with this:

shed_tools/toolshed.g2.bx.psu.edu/repos/devteam/package_rpy_1_0_3/82170c94ca7c/package_rpy_1_0_3$ hg diff
diff -r 82170c94ca7c tool_dependencies.xml
--- a/tool_dependencies.xml	Tue Apr 01 10:47:51 2014 -0400
+++ b/tool_dependencies.xml	Tue Nov 22 10:35:19 2016 -0500
@@ -3,6 +3,9 @@
   <package name="R" version="2.11.0">
       <repository changeset_revision="6e1b17857732" name="package_r_2_11_0" owner="devteam" prior_installation_required="True" toolshed="http://toolshed.g2.bx.psu.edu" />
     </package>
+  <package name="numpy" version="1.7.1">
+      <repository changeset_revision="0c288abd2a1e" name="package_numpy_1_7" owner="devteam" prior_installation_required="True" toolshed="http://toolshed.g2.bx.psu.edu" />
+    </package>
     <package name="rpy" version="1.0.3">
       <install version="1.0">
           <actions>
@@ -15,6 +18,9 @@
                   <repository changeset_revision="6e1b17857732" name="package_r_2_11_0" owner="devteam" prior_installation_required="True" toolshed="http://toolshed.g2.bx.psu.edu">
                       <package name="R" version="2.11.0" />
                     </repository>
+                  <repository changeset_revision="0c288abd2a1e" name="package_numpy_1_7" owner="devteam" prior_installation_required="True" toolshed="http://toolshed.g2.bx.psu.edu">
+                      <package name="numpy" version="1.7.1" />
+                    </repository>
                 </action>
                 <action type="make_directory">$INSTALL_DIR/lib/python</action>
                 <action type="shell_command">

and then uninstalling/reinstalling rpy 1.0.3.

This was the path of least resistance given the current state of the packages in the toolshed (rpy not requiring numpy).

However, the correct fix is most likely to have rpy require numpy (like in current github-only copy, numpy version is up for debate), and simultaneously update any tools using rpy to not manually require their own version of numpy, thereby getting the version inherited through the rpy dependency chain.

@blankenberg
Copy link
Member Author

During a chat, @martenson also pointed out that an other good option is to move to conda only for any effected tools.

@pvanheus
Copy link
Contributor

Is there an (easy) way to discover how many tools would need to be changed? Also how would @martenson's suggestion resolve this? Is the proposal to make linear_regression and other similar tools use conda for dependency resolution?

@martenson
Copy link
Member

@pvanheus there is planemo shed_diff, also IUC has better maintainers and auto-upload to MTS on PR's successful tests (which works great with conda-enabled tools)

@lparsons
Copy link
Contributor

lparsons commented Feb 3, 2017

Any updates on this? I'm running into this issue.

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

No branches or pull requests

4 participants