Hi Aaron,
thanks for keeping on this.
I personally don't have a problem with requiring an R package.
In fact, users will have a rather limited experience with R if they cannot
install add-on packages (for whatever reason) - this is one of the things
that makes R such an attractive option for data analysis.
While there might be some IT departments that are very restrictive, I also
think (no data behind this) that the majority of our users are not in that
situation.
Anyway, that's my two cents worth.
​Cheers,
Andreas


On 23 August 2014 18:02, Aaron Ecay <aaronecay@gmail.com> wrote:

> 2014ko abuztuak 19an, Achim Gratz-ek idatzi zuen:
> >
> > Aaron Ecay writes:
> >> R is capable of installing packages to a user-specified directory,
> >> without requiring root or any other special privileges.  So IT cannot
> >> literally prevent R users from installing their own packages;
> >
> > They can, all they have to do is to take away the ability to connect to
> > the outside network and that's what is increasingly being done (for
> > other reasons, mind you).
> >
> >> the requirement must rather come as a statement of policy.
> >
> > That is another common thing, if only to shift the responsibility if the
> > other measures don't actually prevent that.
> >
> >> I’d like to
> >> understand more about how such regimes work and how org could work
> >> with them, ideally from people who have direct experience with them.
> >
> > Ideally, don't require the use of a non-core package.  The beef with
> > things like CTAN, CRAN or CPAN is that they require extra maintenance
> > beyond the pure installation of some software and some specific
> > knowledge of the software in question and that's just not going to
> > happen in some places.
> >
> >> Otherwise, it would be disappointing if the fear that an unidentifiable
> >> somebody somewhere might not be able to install R packages derailed the
> >> improvement of babel’s R support.
> >
> > The request was to keep a fallback to core.  I have no comment at this
> > time if it would be possible or not.  Since ultimately it's the session
> > support of Emacs that is clunky (and that affects most other languages
> > as well), maybe an effort to improve that would be more generally
> > helpful than working around it in different ways in each language.
>
> Well, I think that it’s going to be difficult to make babel a better
> literate programming solution for R if we restrict ourselves not to
> use the state-of-the-art R package for low-level literate programming
> support.  Org is full of features which one needs to install other
> software to use, and I’m comfortable with the idea that babel’s R
> support should require the evaluate package.  However, it’s difficult
> to argue this point of view when no one has spoken up about their own
> requirements, and a spirit of conservatism in the face of vague
> imagined difficulties persists.
>
> The attached patch fixes the problem that touched off this thread.
> It’s only debatably nicer than the present approach, but it has the
> independently desirable property of segregating babel-driven output
> from the session buffer.  It incorporates what I think is a fix for
> the tramp bug Charles pointed out.
>
> It’s as yet only lightly tested, and as always comments are welcome.
>
> --
> Aaron Ecay
>
>