Bugzilla Bug 189106

New version of Emacs Speaks Statistics has been released.

Reproducible: Always

Steps to Reproduce:
1. mkdir -p /usr/local/portage/app-emacs/ess/files
2. cp /usr/portage/app-emacs/ess/ess-5.3.3.ebuild
/usr/local/portage/app-emacs/ess/ess-5.3.5.ebuild
3. cp /usr/portage/app-emacs/ess/files/50ess-gentoo.el
/usr/local/portage/app-emacs/ess/files/.
4. ebuild /usr/local/portage/app-emacs/ess/ess-5.3.5.ebuild digest
5. emerge -v app-emacs/ess

Actual Results:  
Emerges app-emacs/ess-5.3.5

Expected Results:  
Emerges app-emacs/ess-5.3.5 (everything works fine)

Doesn't appear to be anything new that requires editing of the ebuild, i.e.
just a version bump really, so I've not added any ebuild.

bumped, as you work with it...would a dependency on dev-lang/R be helpful and
how do the two packages interact?

(In reply to comment #1)
> bumped, as you work with it...would a dependency on dev-lang/R be helpful and
> how do the two packages interact?
> 

Not sure if making dev-lang/R a dependency is _completely_ necessary as ESS
provides a way for Emacs to interact with a range of statistical packages, not
just R.  It currently supports R, S-plus, Stata, SAS, BUGS/JAGS and XLispStat.

Thus one could argue if one supported stats package is a dependency, why not
the others?  (Obviously the proprietary ones would be excluded).  Personally I
don't think it would do any harm to have it as a dependency as you would
actually need at least one of the supported stats packages to actually do
anything useful with ESS, but I'd imagine anyone installing it would already be
aware of this and have it installed.

In essence ESS is simply an Emacs mode for interactive analysis of your data
using one of the above stats packages.

My typical work-flow involves writing R (*.R files) or Stata code (*.do files;
learnt to use Stata years ago before coming across R) under ESS mode and
sending chunks to a relevant R or Stata session that is running within Emacs. 
Eventually I end up with a script that does all the analysis required for a
piece of work that can then be archived.

I guess at the end of the day its more a question of whether making R a
dependency fits in with the gentoo 'philosophy'.

Sorry if thats a bit of a waffle and not much help,

Neil

That statement is useful.  I just saw messages running by when test-emerging
saying "R not found, proceeding".  So we leave it like that.

Neil, another question: There are now five versions of ess in the tree, the
oldest being from 2004. If we clean up at some point, is there any virtue in
keeping the last 5.2.* version? (In other words, are there incompatibilities
between 5.2 and 5.3, so that some users would like to continue using 5.2?)

(In reply to comment #4)
> Neil, another question: There are now five versions of ess in the tree, the
> oldest being from 2004. If we clean up at some point, is there any virtue in
> keeping the last 5.2.* version? (In other words, are there incompatibilities
> between 5.2 and 5.3, so that some users would like to continue using 5.2?)
> 

No I don't think there would be any problems in cleaning out ess-5.2.* ebuilds.
 Syntax and key-bindings are all fairly stable across versions, and there's not
really that much that could go wrong as its just a mode for Emacs.  Most
problems occur when new R/Stata/SAS/S-plus versions come out, but thats a
separate issue from ebuilds for ess.

Its a while ago, but I don't remember any problems when I made the change, and
a quick browsing of the mailing list archives after the major version bump
didn't reveal any threads relating to incompatibility.