-
Notifications
You must be signed in to change notification settings - Fork 1k
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
R installations possibly broken #919
Comments
working on this ... |
@bgruening @yhoogstrate Your fix is wrong, it will return 0 also if It works correctly for me on the command line. |
@nsoranzo for some reason the tryCatch is not working for all users. Including a new idea using Python to catch the error. |
I guess |
@nsoranzo even the old version was working for me in one R version :) |
This is what I get:
|
Test 1: correct package, incorrect destination:
Test 2: incorrect package, correct destination:
Edit
|
Yep, it looks like an invalid package name raise a warning instead of an error. Should we exit with |
@nsoranzo I haven't done this because I fear that during compilations there are a lot of warnings. |
Should be fixed by nsoranzo@f666b05 |
@nsoranzo The three tests cases I wrote in the comment above work currectly using nsoranzo@f666b05 |
@nsoranzo your last one works for all of my examples. You probably want to include a few more strings to grep for, as shown by @yhoogstrate. Not sure if all are errors or a few of them are warnings. Please decide yourself if you want to have this one-liner or if we want to create a Python template without tryCatch(). The grep functions seems to be stable since 2.11 so this could be a valid solution. |
@yhoogstrate How can I reproduce |
This makes me realize that your grep should not be able to capture this warning, but it still returns an error. I think we should look a bit closer into it, unless I made a mistake in copy pasting:
|
@yhoogstrate The problem is that I should have used |
@nsoranzo Thanks, it works here. I think you should make a PR and in the meantime we should test the packages within: package_dexseq_1_14 |
Awesome, thank you guys! |
this is still not ideal, as the entire response will be loaded into memory. This is a problem with streaming responses. encode/starlette#1012 (comment) is actually enlightening here: > "This means this class will either load the entirety of streaming requests into memory (this issue) and run the background before returning the response (galaxyproject#919 ), or if we fix those problems, that it will then encourage users to leave resources in a pending or open state, an arguably worse result. In short, it's problematic." Which is exactly what we'd be doing with a middleware, keeping resources open for longer than necessary, which we need to avoid if we ever want to run background / async tasks. I think the solution here what we already had, path operation dependencies.
this is still not ideal, as the entire response will be loaded into memory. This is a problem with streaming responses. encode/starlette#1012 (comment) is actually enlightening here: > "This means this class will either load the entirety of streaming requests into memory (this issue) and run the background before returning the response (galaxyproject#919 ), or if we fix those problems, that it will then encourage users to leave resources in a pending or open state, an arguably worse result. In short, it's problematic." Which is exactly what we'd be doing with a middleware, keeping resources open for longer than necessary, which we need to avoid if we ever want to run background / async tasks. I think the solution here what we already had, path operation dependencies.
details here: #893 (comment)
ping @yhoogstrate @mvdbeek @bgruening @jmchilton
The text was updated successfully, but these errors were encountered: