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

RemoteRScriptRepository and GitHubScriptRepository #80

Open
nuest opened this issue Apr 25, 2014 · 9 comments
Assignees

Comments

@nuest
Copy link
Member

@nuest nuest commented Apr 25, 2014

Implement an abstract class RemoteRScriptRepository that can manage scripts from remote locations, namely URLs or URIs. On startup scripts are copied into a local directory (based on an an abstract method public abstract Collection<InputStream> getScripts() and then loaded. The loading functions can probably be re-used from the LocalR...Repository. The remote repository should allow to set a fixed interval on which it updates the local copies of the scripts.

The GitHubScriptRepository will allow to define a GitHub username and repository name and from that information download the R files from that repository.

@autermann

This comment has been minimized.

Copy link
Member

@autermann autermann commented Apr 25, 2014

Or the GitHub API (https://developer.github.com/v3/repos/#get), e.g. https://api.github.com/repos/52North/WPS - but I didn't find an option for file download...

You don't need the API for that:

https://github.com/$USER/$REPO/archive/$BRANCH_OR_TAG_OR_COMMIT.{zip,tar.gz}
@nuest

This comment has been minimized.

Copy link
Member Author

@nuest nuest commented Apr 28, 2014

Right - that gives me access to a zipped copy of all the current files, e.g. https://github.com/52North/WPS/archive/master.zip - and I can unzip that and look for all the .R files in it.

Thanks for the tip! I think this is a good solution for a first prototype.

@nuest

This comment has been minimized.

Copy link
Member Author

@nuest nuest commented Apr 28, 2014

The "remote" could also be any file URL that is local for that matter and use the same behaviour for additional (or the current R/scripts directory as well!) script locations and resource locations - just copy them all into a temporary folder, no mischief happening in that controlled location.

@nuest

This comment has been minimized.

Copy link
Member Author

@nuest nuest commented Apr 28, 2014

Together with #76 this would allow to move the demo R scripts out of the 52n-wps-webapp module into the 52n-wps-r - module into src/../resources, which would be an important improvement for decoupling of the webapp module.

@nuest

This comment has been minimized.

Copy link
Member Author

@nuest nuest commented Jun 6, 2014

@matthias-mueller fyi - I want to tackle this issue soon to be able to collaborate more easily on R script development, for merely practical reasons. Conceptually this is probably related to your mc-work.

@matthias-mueller

This comment has been minimized.

Copy link
Member

@matthias-mueller matthias-mueller commented Jun 6, 2014

Yes; let's have a brief talk then to see if we can align the workspace structure.

@nuest

This comment has been minimized.

Copy link
Member Author

@nuest nuest commented May 20, 2015

By now I would prefer using JGit from the start, it allows to also update the local clone outside of the WPS, for example.

Related and maybe also interesting: rgist package to access gists from R.

@matthias-mueller

This comment has been minimized.

Copy link
Member

@matthias-mueller matthias-mueller commented May 20, 2015

Okay, let's see where this goes. I see four or five things that we have previously discussed within the repository concept:

  1. Access to executable workspaces or code
  2. Access to related source code (especially important for byte code)
  3. Versioning
  4. Documentation
  5. Link with github due to its widespread use

I'd be glad if we could keep things as simple as possible, i.e. not force our users into complex solutions if they just want to upload a simple script. Although I have a strong affinity to using GIT, we should still be able to handle plain (non-git) workspaces and content.

@nuest

This comment has been minimized.

Copy link
Member Author

@nuest nuest commented May 20, 2015

Yes - this is an addition to the simple "drop-in folder" solution that WPS4R already supports.

If you would like to start a discussion on the repository concept in general, could you open a new issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.