Understanding the Structure of an R Package

Hi and welcome to the final section. Till now we've been using many packages created by package authors and contributors in this section. We will learn how to create our own our package creating our packages is not known to be an easy process. This is because the team has put in place an excellent collaborative system to create and maintain packages every package on Crann goes through a protocol and must strictly adhere to the rules. This add significant value to our programming language because our ecosystem is well organized. As a result all packages have a uniform documentation system common structure working code examples and optionally vague nets. This makes it so convenient to become familiar with new packages and techniques in a short time. In this section we will learn about making our packages in detail until it can be submitted on Krahn. In fact we will create in our package from scratch create the documentation do the mandatory checks and host it on get hub. Finally after completing all the checks and verifications I will actually submitted on Crann. Let's start the section by understanding the structure of an R package. In this video we will understand the difference between a library and a package and see the contents of a typical package before we understand the structure of our package. Let's understand what a library is. A library is any directory that contains one or more packages. We can have more than one library and we could see the existing libraries using lib paths. When we call the library function or will look up the directories in live paths we can instruct our to look for packages from a new library like this nice. Let's now see the components of a typical R package. Therefore mandatory components that go into any R package the most significant one is the R directory which contains all the R files. These are Pyles in turn hold the functions provided by the package. There is an optional z z z. R file which normally holds functions for package startup messages. Next is the description this is the file that shows when we use help when calling library function. We will go over the fields when we create the package in the next video. Next is the namespace this file lists the functions exported by the package and those that it requires from other packages the export and import from statements are used to make these declarations. Finally there is the man folder short for manuals. It contains the documentation's in the form of d files that goes with the package. We will see how to create them in the upcoming video. In addition to the minatory items there are a few others that packages may have. For example if you provide additional data sets it could be placed as datt our data files in the data folder. Likewise the big nets folder contains any PTF or RMV files used to make the package vagueness which provide additional documentation and examples for use in the package vs RC folder short for source contains any C++ or C files used to generate compiled code. There could be other items such as tests folder that contains unit tests to make sure the package works the way it is supposed to. Finally there is a license file. So those are the primary components of our package. We will be creating several of these components in the next video. It could seem like hard work on the first look but it isn't as hard as you think because our studio provides nice facilities to automate a large part of the setup. We will see this in more detail in the next video with an actual example in the next video. We will build and document in our package from scratch and hosted on get hub for anyone to use.