Re: packaging stan
Hi Ross
On Sat, Aug 03, 2013 at 08:06:16AM -0700, Ross Boylan wrote:
> I am thinking of packaging stan and rstan, and would appreciate some advice.
Nice.
> stan is a program for doing Bayesian analysis with a variant of
> hybrid/Hamiltonian monte carlo. http://mc-stan.org/ homepage; https://github.com/stan-dev/rstan.git
> and https://github.com/stan-dev/stan.git for code.
>
> It looks to me as if there are substantial parts of the source that
> should not be in the debian source;
> http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-origtargz
> indicates this is possible, but not generally advisable. I'd
> appreciate feedback on how to handle this both in policy terms--what
> if any parts should I omit, and practical terms--best mechanics of
> doing this with an upstream git. Most of the other packaging
> documentation I've reviewed is silent on this topic (except for
> mentioning some git-specific helpers).
Without inspecting the source in detail myself I'm not fully sure what
you might mean with the paragraph above but I will try to answer the
issues below.
> In particular, stan includes a lib directory of external libraries.
> I assume a debian package should use already packaged versions of
> those libraries.
Yes. This is what we put some effort into. It is very advisable for
several good reasons.
> I'm assuming stan has not locally modified the
> libraries.
It is most probably a good idea to ask the upstream authors about this.
> Also, rstan includes stan as a subproject; I assume I would package
> the source would not. Though perhaps one source could be used to
> build stan and rstan.
As I said I did not checked the source. If both programs might come in
one source it is possible to build two binary packages from one single
source package. There are a plenty of examples in our archive - just
ask if you need a more specific pointer.
> The system itself is fairly complicated; stan works by translating a
> program into C++ and then compiling the program at run-time. Also, it
> includes a library as well as a front-end program.
>
> rstan an R package designed to call stan from R. It is set
> up so that one downloads the R package and, while installing it in R,
> the whole stan system gets built (so the R library source includes all
> of stan).
>
> The directory structure of rstan is a bit odd; the "real" R library
> source is in
> https://github.com/stan-dev/rstan/tree/develop/rstan/rstan, with the
> higher directories having meta-stuff (maybe the web page and tools for
> building the package including stan).
Hmmm, I only know R packages from CRAN and the packaging is very simple
and straightforward. You can basically copy the stuf from another R
package and rename the basic things. Seems this is not the case here.
:-(
> I'm not a debian developer, but I figured since I was interested in
> using the package I might as well try to package it. stan is not
> listed for wnpp.
If you are no (not yet) a Debian developer that should be no problem.
In Debian Science team we have some tradition of inviting people who
are willing to work and we are propagating your work via so called
Sponsoring to the Debian mirrors. For Blends related packages (which
would fit here) I have a specific offer of "Sponsering of Blends"[1]
> Comments or suggestions welcome.
Hope this helps for the moment.
Kind regards
Andreas.
PS: Apropos Monte Carlo: Does anybody know
http://www.gel.usherbrooke.ca/casino/What.html
and is there any Free Software alternative?
[1] https://wiki.debian.org/DebianPureBlends/SoB
--
http://fam-tille.de
Reply to: