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 <aarone...@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 > >
