-
Notifications
You must be signed in to change notification settings - Fork 20
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
Do we need to add "setDefaultBaseUrl" function to RCy3? #69
Comments
I would need to see a demonstration of this. I didn't know it was possible! The use case I know of would have RStudio and Cytoscaped installed in the same VM, so 'localhost' would be correct. |
But, regardless of the Docker use case, I think you're probably correct, that |
Wait, that's why Users can set default base url with a simple assignment; no function needed, e.g.,
|
I think your example
does not work. The demonstration of this is
|
And these commands also do not work
|
This turned out to be more interesting than I had thought... You are correct that setting the value of Of course, there is a package for cases just like these and it's called To change the default value of a package function, you would do this:
And you can restore package defaults with this:
You have to run this for each function you want to change. |
Not sure which is easier...
I guess it will depend on the nature of the script and the user's preference. |
If you change "base.url=.defaultBaseUrl" into "base.url=defaultBaseUrl" for every function, it works. So why not change this? |
@229668880 Thank you for your comment. |
I use RCy3 in R REPL in one Windows PC. I try to connect R to the Cytoscape in the other Windows PC. .defaultBaseUrl='http://192.168.1.1/v1' cytoscapeVersionInfo(.defaultBaseUrl) # this doesn't work So, do all functions should be changed to take defaultBaseUrl intead of .defaultBaseUrl? |
@229668880 What I'm looking for seems to be different from what you say. |
Ok. I learned a new trick that might be relevant here. We added internal variables for delays last release and there was a request to provide a function to make this adjustable by the user. My first thought was, "oh no, another parameter is a bunch of functions." But I ended up learning how to define a cache environment where we can Scenario 1: default base URL. Nothing would change for this common user scenario. A default value for .BASE_URL will be assigned when the package is loaded. Scenario 2: custom base URL. I can expose a function called setBaseUrl(url=***). The user can call this once and it will work for all functions in the package. The user can call the function without an arg to reset to the default. I believe this is what @kozo2 and @229668880 (above) originally wanted, but I didn't not know to implement this before. I will give it a try in a branch. Can you help test? Example of variable assignment, usage and setter function. |
@AlexanderPico Thank you for the information. RCy3-utils.R
RCy3.R
*.RReplace all |
Almost. You've got the That should work, right? |
Note that there is some strong advice against using global variables: https://stackoverflow.com/questions/12598242/global-variables-in-packages-in-r. In this advice, they actually say that it is better to do it the way we are currently doing it, by passing variables around in every function. So, I'm not totally convinced yet that my latest idea is a good one... In practice, let's imagine a workflow script that uses 12 functions from RCy3. Currently, if the end-user wants to use specify a base.url, they might define In the proposed approach, they would define HOWEVER, if they run another script in that same R session, then it will also be using this new base.url. It stays until they either reset it or they reset their R environment or reload the RCy3 package. I think this is where the advice against this approach is centered: it can lead to unexpected behaviors that are difficult to troubleshoot. So, what I need to know from end-users who have to specify an alt base.url is which would be more painful for you? (1) Explicitly setting base.url in each function, where it's clear and easy to troubleshoot, or (2) Setting it once in your scripts and having to be aware of the value of that hidden variable at all times. In real world use cases, do you simply always want it to be an alternate value (like using a special port for CyREST) or do you need to change it for various scripts within an R session? |
Alex
For what it’s worth, we don’t mess with the base URL in any way
right now. I would rather not have to set it up each time.
=$0.02
Mark
University of Montana
…On 8 Mar 2021, at 13:26, Alexander Pico wrote:
Note that there is some strong advice against using global variables:
https://stackoverflow.com/questions/12598242/global-variables-in-packages-in-r.
In this advice, they actually say that it is better to do it the way
we are currently doing it, by passing variables around in every
function.
So, I'm not totally convinced yet that my latest idea is a good one...
In practice, let's imagine a workflow script that uses 12 functions
from RCy3. Currently, if the end-user wants to use specify a base.url,
they might define `my.base.url=***` at the top of their script and
then they have to be aware to include `base.url=my.base.url` as a
param in each of the 12 functions in their script.
In the proposed approach, they would define `setBaseUrl=***` once at
the top of their script and then it would just work.
HOWEVER, if they run another script in that same R session, then it
will also be using this new base.url. It stays until they either reset
it or they reset their R environment or reload the RCy3 package. I
think this is where the advice against this approach is centered: it
can lead to unexpected behaviors that are difficult to troubleshoot.
So, what I need to know from end-users who have to specify an alt
base.url is which would be more painful for you? (1) Explicitly
setting base.url in each function, where it's clear and easy to
troubleshoot, or (2) Setting it once in your scripts and having to be
aware of the value of that hidden variable at all times.
In real world use cases, do you simply *always* want it to be an
alternate value (like using a special port for CyREST) or do you need
to change it for various scripts within an R session?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#69 (comment)
|
Thanks Mark. This change would only affect end-users who have to specify an alternative base.url. For you and 99% of other users, there would be no change regardless of the solution we go with here. |
@kozo2 @AlexanderPico How do I connect RCy3 on bioc image container to local cytoscape? my |
@OmarAshkar Sorry I didn't see this comment. Please open new issues in the future to get better attention. Regarding your use case, I'm not familiar enough with bioc image containers. Assuming is something like running a Docker container on a server with RCy3 in it and wanting it to communicate with a local Cytoscape, well that is very tricky indeed! Setting your base.url will NOT work. The base.url is to tell CyREST how to connect to Cytoscape. However, we are also interested in support this cloud-local scenario and have a ton of work implementing a Jupyter-Bridge technology. This will allow Jyputer-hosted scripts running RCy3 to work with local Cytoscape instances. This will be available in the next major release of RCy3 (late May 2021). |
Some users may want to run RCy3 from Bioconductor Docker RStudio or WSL2.
In such case, I think we need to add
setDefaultBaseUrl
function to RCy3.(Becase writing
base.url =
option every time is bothersome.)What do you think about this?
The text was updated successfully, but these errors were encountered: