Turn into an installation package about addinslist

[jwijffels]

addinaddon

[daattali]

Good idea. Ideally, there would be a CSV file that lists all the addins, and that's the file people would have to edit if they want to add a new addin. The README should be automatically generated based on the continuously updating CSV. I'll have to think about how this will work exactly (automatically re-generating the README without me manually needing to recompile it), but it's a nice idea for the future, after I graduate

[calligross]

One idea might be to move to github.io and use Jekyll's data directory + csv.

But I haven't test it yet myself.

[daattali]

Ideally I'd like to keep it as simple as possible, so don't require jekyll, just be a simple README in a repo that users look at. I wonder if there's a way to run a script/force running an Rmd when a file is updated. Not critical right now, will deal with it in a few weeks

[daattali]

@oganm @calligross
I just realized a potential problem with what I was envisioning. It would mean that one you install this package, you have a list of RStudio addins that were available at the time of installation. But if people add more addins to the list over the next month, you'll only get them if you update the package.

So, how about this: every time you run the addin manager, it can fetch the README.md from this repo, parse the table , and display the most up to date information. It might be a little bit hacky but I think it'll work just fine. Parsing the table in the README would be pretty simple, since each column is separated by a |.

Thoughts?

[oganm]

Makes perfect sense to me. I did want to write a short function that returns tables in md files. I can deal with that in a spare time

[daattali]

I think a couple good things to do just to be a little bit safer are:

• include an identifying HTML comment before and after the table, as sort of a "start here"/"end here" markers. HTML comments don't show up in the markdown so it won't affect the users.
• the function would probably return a JSON or list of lists for the table (every row is a list, the entire table is a list of these lists). And it should try to go line-by-line with strict error catching, so that if one line is malformed and does not parse properly, instead of completely failing, we just exclude that one line from the returned list of rows

[daattali]

I added table:start and table:end comments. This would of course be in case there are any other tables in the README in the future. Not likely, but a good practice

[daattali]

Suggestions from twitter conversation about this:

• use rmarkdown::pandoc_convert to convert the markdown to HTML and then use rvest to parse the HTML and find the tables
• alternatively, use commonmark to convert the markdown to html using a c library instead of pandoc

[daattali]

@oganm you're my go-to for "what should I name this thing": if we package-ify this , what's the package name? rstudio-addins is an illegal name (and it's not a good name for the package anyway)

[talgalili]

@daattali what about addins4rstudio
?

[daattali]

It's an option. I prefer not to mix numbers between words ideally
On 2016-04-07 1:20 AM, "Tal Galili" [email protected] wrote:

@daattali https://github.com/daattali what about addins4rstudio
?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9 (comment)

[Stan125]

Hi guys,
An Add-In to install RStudio Add-Ins which is preferably updated over one comprehensive list is a great idea which I have thought about myself.
My take on the name: CLARA (Comprehensive List Archive for RStudio Add-Ins)

[Stan125]

Additionally, I just created a repo to download the newest RStudio Add-In list, parse it and read it into a dataframe. All Add-In names and info can now be accessed, however I could not scrape the links out of the HTML file. If someone would add the functionality to include the links to the Add-In packages into the dataframes, we could easily wrap it up in an Add-In.

[daattali]

That's a nice alternative to "CRAN". I think names that are less cryptic
and clear about what they do is better for discoverability though. So maybe
just rstudioaddins or addinsrepo?

And I was thinking it'd be a smooth user experience if the list and the
package are one and the same (hence I put skeleton package code here)
On 2016-04-07 12:11 PM, "Stanislaus Stadlmann" [email protected]
wrote:

Additionally, I just created a repo https://github.com/Stan125/clara to
download the newest RStudio Add-In list, parse it and read it into a
dataframe. All Add-In names and info can now be accessed, however I could
not scrape the links out of the HTML file. If someone would add the
functionality to include the links to the Add-In packages into the
dataframes, we could easily wrap it up in an Add-In.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9 (comment)

[oganm]

@daattali addinstaller? @Stan125 you're downloading an html file not a markdown so the markdown html conversion step is redundant but ideally you would access the markdown file directly through the "raw" page. but its nice to know that a parser might not be necessary

[daattali]

@oganm punny as always! I think that's the best so far. The only thing that'd be better if is if it was clear that it's an installer but ALSO reflect the fact that this repo is a list/repo/resource for addins

[daattali]

@oganm @Stan125 Sadly, it looks like commonmark (ported to R by @jeroenooms) does not support markdown tables (it expects tables in markdown to be coded as HTML)

So the alternative are:

• download the markdown, parse the table manually
• download the markdown, use rmarkdown::pandoc_convert to convert it to HTML, parse the table with rvest
• download the HTML page, parse the table with rvest

I'm leaning towards option 2. It might seem more indirect than method 3, but I feel like it's safer and will be more stable. Though pandoc_convert requires a file (it doesn't deal with text), so the downloaded markdown has to live as a file which is a tiny bit annoying

[oganm]

@daattali
aPackageThatIsAListOfAddinsAndAlsoAnInstalleR
addinstallist
addinbox
a'dean'box

html page download can potentially be effected by changes to github even though it is unlikely. 2nd option indeed seems better

[daattali]

I've done some initial work, just to see how feasible this is. Turns out having to parse through the markdown while still optimizing the markdown document for READERS is pretty annoying, because I don't want to force people to add a "unique ID" to each row, and dealing with links inside a markdown isn't very nice either. The code I committed is really really bad, do not judge my coding abilities from that please :) It's just a very rough proof of concept

[ottlngr]

@oganm @daattali
How about AddinStallR - some kind of portmanteau word from "addin", "install", "stall" and "R" ?

[daattali]

thanks for all the suggestions, it'll be changed to something more sensible soon. I like the last two, except for the fact they both mainly target the fact that it's an installer, but not a list. I do want the repo README to server a big purpose too, I don't want it to just become a package only. I'm getting very picky, I know!

I spent a few hours mocking up something super ugly and semi functional. Feedback welcome. (I wouldn't be surprised if it doesn't install/work for someone, it's very hacky at the moment)

devtools::install_github("daattali/rstudio-addins")
rstudioaddins::gadget()

[ottlngr]

oh that is pretty cool!
Had to install V8 first but then it worked like a charm!

Did you think of putting the "CRAN-GitHub-Decision" into that "Are you sure u wanna install xy" pop-up? Maybe even displaying the respective version number?

[daattali]

Do you mind actually uninstalling V8, installing the latest shinyjs from GitHub, and see if it works? I think the V8 requirement is a bug that I fixed a few days ago.

I didn't put the cran/github decision inside the popup because there's a checkbox to remove the popup completely. Version # would be a nice touch I suppose, but it'd require an online query, I'm not sure it's worth it? Do you think it adds much?

[daattali]

@ottlngr Whoops, scratch that -- the V8 thing was my bad. It should now work without V8 (and without requiring a new shinyjs version).

[ottlngr]

Well it depends of course. But if you think of ggThemeAssist for example: We added a whole bunch of features during the last weeks that have still not seen CRAN yet. So the version number thing would be like 'Hey, you might miss something when installing from CRAN'.

[daattali]

True. Though I generally think it's common knowledge that if you want latest version you go to GItHub, if you want stable release you do CRAN, is it not?

[ottlngr]

Well of course you're right.

I don't want to be pushy, but:
Why is it common knowledge (<- topic of my MA-Thesis, btw :D ) that you have to check GitHub if you want the latest (stable) release? Because the general way of installing R packages is install.packages() which install from CRAN exclusively. There's simply no way (as far as I know) to check for a newer release from within R.
Establishing a package like this which deals as a man in the middle between the user and CRAN/GitHub would enable this feature. Definitely not a must, but a worthwhile feature in my opinion.

[daattali]

How would the version be checked without adding a lot of complexity? There's probably some API to check for latest CRAN version, but I doubt there's a way to check for a GitHub version, unless you know of any? So it'd have to scrape the DESCRIPTION and find the version in there?

If you're feeling strongly about this, it's probably better if you open a separate issue and tag it as "enhancement", because it'll get lost forever in the long thread here

[ottlngr]

I know that it would be a huge hassle. I'll think about it and chime in on that again as soon as I have a clear idea how this could work.

[daattali]

Cool - open a new issue specific for that when you have ideas

[calligross]

A second best solution would be the latest release on GitHub. But I don't know the api.

Markus Groß
Schweizer Str. 65
60594 Frankfurt

Am 08.04.2016 um 14:08 schrieb ottlngr [email protected]:

I know that it would be a huge hassle. I'll think about it and chime in on that again as soon as I have a clear idea how this could work.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[daattali]

I don't think most packages have proper "releases", so not sure how useful that'd be

[calligross]

Probably, but that might be an incentive to use it. At least it is only one click.

Markus Groß
Schweizer Str. 65
60594 Frankfurt

Am 08.04.2016 um 14:14 schrieb Dean Attali [email protected]:

I don't think most packages have proper "releases", so not sure how useful that'd be

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[daattali]

The convo here steered away from the orginal issue (which was about making a package, which is now done). Any further ideas should be their own issues