Simplified installation and configuration procedure

[richfitz]

No description provided.

[jackolney]

Can I suggest something akin to jackolney/clustr? This will now work easily for others and wraps around didehpc (just noticed the name change, nice)

clustr allows:

• Automatic login from ~/.smbcredentials (if present)
• Simplified selection of cluster: "MRC" or "DIDE" vs. fi--didemrchnb or fi--dideclusthn
• All packages named in one vector e.g. packages = c("devtools", "hadley/ggplot2") and they will be teased apart into those required from CRAN / GitHub
• All done with one function call to login

[richfitz]

Hmm, not sure.

• installation of the core tools should now be as simple as: source("https://dide-tools.github.io/didehpc/install") (don't run that unless you want to upgrade, in which case check the porting guide. Particularly, I cannot recommend devtools::install_github because of the mess that it regularly leaves windows machines in (I see you're using it within your login function
• I like the idea of cluster name aliasing - I'll add that to the main package. The headnode names are used elsewhere though so I'll need to keep them as an option
• after things are generally working the first time, web_login() should not be explicitly needed. The new version also attempts to detect if it can avoid re-requesting a password
• The global config options I am now (finally) officially setting via .Rprofile

The package specification thing I explicitly moved away from - I'd used this previously and it eventually falls short, not least because determining the package name from a github repo is depressingly not always straightforward

[richfitz]

I'm thinking that an ask based interface might be nice, but it involves writing to people's .Rprofile - that could be avoided by using startup but then we are building a bit of a chain of dependencies.

[jackolney]

+1 for the ask based interface - never really seen this type of interface used in R. Only concern would be whether responses can be scripted / automated.

[richfitz]

That's the issue; they can't really. I need this information to end up in people's .Rprofile files and in the script they're writing but in general don't want to mess around with these too much. Some things like the username stuff will apply all the time, some like cluster will apply most of the time, and others (workers, timeouts, progress bars, etc, etc) will be very project specific