I've already used devtools to create my package skeleton, then added a bunch of R code, metadata, documentation, etc. I would like to use rstan within this package. I understand that rstan::rstan.package.skeleton creates a package skeleton to facilitate this. So what is the best practice for augmented an existing package with the structure necessary to use rstan from that package? Thank you.
I would say to use rstan.package.skeleton to create the skeleton in a temporary directory and then copy the relevant stuff it creates into the package you created by devtools. This would include
cleanup and cleanup.win in the root of the directory
the tools directory
the exec directory
the inst/chunks subdirectory
the src directory
the R/stanmodels.R file
the DESCRIPTION file in the root of the directory
For the DESCRIPTION file, you may just have to combine it by hand with whatever DESCRIPTION file you have currently.
Related
In Haskell: Given an existing directory tree (with sub-directors) of source files.
Is there a way to get a .cabal or .stack file, created automatically, with all the necessary dependents (references to the import files that are embedded inside the source file) embedded in the command file,with no need to manualy editing the command file.
In other words, get a command file that I will be able to run "straight out of the box" without the regular methods of stack new/stack build etc,commands?
cabal init will create a file that lists all the modules in your sourcedir for you. But you will still need to provide the package dependencies yourself. This is because a module Foo.Bar.Baz may come from multiple packages -- hence the package you intend to import must be explicitly specified.
How can I add a path to my current path in Julia, so that I can organize files and modules in folders, but still access them?
Note: the following paths may be Unix-specific.
You can add the file .juliarc.jl to your home directory, and include the line
#everywhere push!(LOAD_PATH,"/path/to/my/code")
The #everywhere ensures that it will work even if you've started julia with multiple workers.
This is an updated and extended version of the answer by tholy and ederag. On Linux and Windows with Julia 1.0 one can add the folder myproject/src in the user homefolder to the Julia LOAD_PATH by adding
using Distributed
#everywhere push!(LOAD_PATH, joinpath(homedir(), "myproject", "src"))
to <homedir>/julia/config/startup.jl. For a fresh Julia install, startup.jl nor the folder config exists (on Linux at least). Just create the file and folder and Julia will read startup.jl automatically.
When defining a package, Is it possible to put the bower.json file inside a subdirectory of my git repository, and reference it in other projects?
I know that the docs says to put it in the root, but I already have my own directory structure on my git repository and want to put it inside a subdirectory.
I'm wondering if exists an option inside .bowerrc file to configure bower.json location. That would solve my problem.
I know this question is pretty old but none of the answers address the OP's actual question.
It is possible to store your bower.json in a subdirectory of your project (or another project for that matter).
In your .bowerrc, use the cwd (current working directory) setting to specify where your json file is stored.
More info can be found in the bower configuration docs.
Bower will create the ./bower_components folder next to the bower.json file.
So, as long as you ensure that the paths of the js/css files are OK, you can put the components wherever you want.
In my case, I have to use different versions/dependencies for an HTML5 mobile app and a Bootstrap/Angular backend. So I have something like that:
/bower.json
/bower_components/
/app/bower.json
/app/bower_components/
Just be sure to include your bower.json files in the GIT tree and add the bower_components folders to the .gitignore file
Hope it helps
I have created some local libraries in my dart lib directory.
These libraries are visible in dart packages for each newly created folder in the web directory. However, when I attempt to access them using the dart's package nomenclature eg package:reg/name.dart, the system always generates an error.
I think I am missing something.
I have read http://pub.dartlang.org/doc/package-layout.html but this did not help me either.
You need to ensure that the name you're using as the package matches that in pubspec.yaml.
Eg. if in pubspec.yaml you havename: my_app and your file is at lib\my_library.dart then you need to use import 'package:my_app/my_library.dart';.
I have an erlang application I have been writing which uses the erldis library for communicating with redis.
Being a bit of a newbie with actually deploying erlang applications to production, I wanted to know if there was anyway to 'bundle' these external libraries with the application rather than installing into my system wide /usr/lib/erlang/lib/ folder.
Currently my directory structure looks like...
\
--\conf
--\ebin
--\src
I have a basic Makefile that I stole from a friend's project, but I am unsure how to write them properly.
I suspect this answer could involve telling me how to write my Makefile properly rather than just which directory to plonk some external library code into.
You should really try to avoid project nesting whenever possible. It can lead to all sorts of problems because of how module/application version is structured within Erlang.
In my development environment, I do a few things to simplify dependancies and multiple developed projects. Specifically, I keep most of my projects sourced in a dev directory and create symlinks into an elibs dir that is set in the ERL_LIBS environmental variables.
~/dev/ngerakines-etap
~/dev/jacobvorreuter-log_roller
~/dev/elib/etap -> ~/dev/ngerakines-etap
~/dev/elib/log_roller -> ~/dev/jacobvorreuter-log_roller
For projects that are deployed, I've either had package-rpm or package-apt make targets that create individual packages per project. Applications get boot scripts and init.d scripts for easy start/stop controls but libraries and dependancy projects just get listed as package dependencies.
I use mochiweb-inspired style. To see example of this get your copy of mochiweb:
svn checkout http://mochiweb.googlecode.com/svn/trunk/ mochiweb
and use
path/to/mochiweb/scripts/new_mochiweb.erl new_project_name
to create sample project of the structure (feel free to delete everything inside src afterwards and use it for your project).
It looks like this:
/
/ebin/
/deps/
/src/
/include/
/support/
/support/include.mk
Makefile
start.sh
ebin contains *.beam files
src contains ***.erl files and local *.hrl files
include contains global *.hrl files
deps contains symlinks to root directories of dependencies
Makefile and include.mk takes care of including appropriate paths when project is built.
start.sh takes care of including appropriate paths when project is run.
So using symlinks in deps directory you are able to fine tune the versions of libraries you use for every project. It is advised to use relative paths, so afterwards it is enough to rsync this structure to the production server and run it.
On more global scale I use the following structure:
~/code/erlang/libs/*/
~/code/category/project/*/
~/code/category/project/*/deps/*/
Where every symlink in deps points to the library in ~/code/erlang/libs/ or to another project in the same category.
The simplest way to do this would be to just create a folder named erldir and put the beams you need into it and then in your start script just use the -pa flag to the erlang runtime to point out where it should fetch the beams.
The correct way (at least if you buy into the OTP distribution model) would be to create a release using reltool (http://www.erlang.org/doc/man/reltool.html) or systools (http://www.erlang.org/doc/man/systools.html) which includes both your application and erldis.
Add the external libraries that you need, anywhere you want them, and add them to your ERL_LIBS environment variable. Separate the paths with colon in unix or semicolon in dos.
Erlang will add the "ebin"-named subdirs to its code loading path.
Have your *.app file point out the other applications it depends on.
This is a good halfway-there approach for setting up larger applications.
Another way is put your lib path in ~/.erlang.
code:add_pathz("/Users/brucexin/sources/mochiweb/ebin").
code:add_pathz("/Users/brucexin/sources/webnesia/ebin").
code:add_pathz("./ebin").
code:add_pathz("/Users/brucexin/sources/erlang-history/ebin/2.15.2").