500: Material on how to create and submit a package to Bioconductor
Kayla Interdonato (Roswell Park Comprehensive Cancer Center)
11:00 AM - 11:55 AM EDT on Thursday, 30 July
This is a two part workshop. The first half of it will walk students through how to create a package using RStudio and the devtools package. This will be an instructor-led live demo, so as the student is creating their own package we will go over what we look for in Bioconductor packages. The second half of the workshop will go over the submission and review process for Bioconductor packages.
Moderator: Lori Shepherd
I am cute interdonato. I am courting member about conductor, probably one of them. I believe one of the newest ones I've been on for about 2 years now, and I was going to do this Workshop about how to create a package and then touch a little bit on how the submission process works for battle conductor. So I have the workshop available on the on the image you can find it under the material on how to create and submit a package that we were running into some issues with basically we're going to be working with
get and a repo and kind of connecting the two of them. So there was some issues with the doctor image and things like that, so you're not to be able to do the full, create a package on the docker image, but I will be working off the vignette that's in the package. So you can load the vignette and kind of walkthrough. I'm going to show you how to do it locally because I really the only package that we're going to be using as decimals. So if you want to follow along locally, you can open up our studio and installed actual and that'll give us all the functionality
that we need to create a package. Otherwise feel free to follow along with his in yet or just watch as I work through this. And I think I'm going to set a timer just to make sure that we stay on track. I want to do that like 15 minutes of how to create a package and what we expect in the package and then I'll do about 15 minutes of the submission and kind of walking through that and then, whatever time we have left will work on some questions and answers. So be sure to be posting your questions in the polls on Impossible and Lori will be keeping an eye on that floor.
He's done his presentation in the past and you probably don't know Lori through the court email, she knows a lot about package creations and things like that. If there's any major issues she can help out in real time. So I'm going to go ahead and get started with some coding because that's what we're all here for. So let me share my screen. And I am going to open up our studio which I have here and the first thing. So what is a package? So you create a bunch of functions and you want to put them together into a cohesive manner of which would be a package which includes things like
documentation which include Man pages and yet we really, really really like test to make sure that the fact is doing what it's intended to do. So we're going to talk a little bit about that through this but the first thing in order to create the package like I mentioned, we're going to need a Deadpool. This package is going to give us the functionality that we need to create the package which I'm going to open this up a little bit and kind of hide some of this because I like to just see my code which maybe I can't.
So the first function that we're going to use from Deb schools is create and this is going to create. So you're just going to use the function tree and then you're going to need your package in the van. Yet I used my first package. We really like camel case. For package names, don't use anything to obscure. I'll trying to talk a little bit about naming packages later on in the submission process. But so we run this and it doesn't bunch of stuff for us,
which I think it's going to pop open this window. So I'm going to ask about that. But The first initially, it creates the increase the directory. My first package is going to set your your project to that. It's going to treat. Our directory is going to create a description filed, the namespace file, the project file, and then a bunch of other little things. So you should see in the list here, my first package, which was the director that was treated. And here is everything. Everything but a majority of what you're going to need for a package. So this gives you just the
bare bones and you can take a look at He's really, really basic something like this. My first package End up here. I'll pop out. This is what the description style looks like at the moment and we will go back and edit this, but this is what you can see for a typical package, some information about it and this was all populated thanks to the create function. So one less thing that you have to do. So we have our package treated, Now, we're going to get a little
bit into Version Control. So when you create a package and especially when you're collaborating up on a project where there are multiple users on people can make changes the Version Control allows so that you can have a record of the changes that you can. You can advance to change the Version Control is really crucial. So I'm going to show you how to stay with this created a directory. So in our studio, we're going to go up here to file new project. And since we already treated the directory, we're going to choose existing directory and we're going to
find it. So I just did it in my home directory. My first package and this is going to be are working directory. So we create the project. Opens up the new one now. And now we are in the my first package directory. It is the my first package project so it did what we would expect to do. Now we have to set up the Version Control so if you go to tools, Version Control project setup. This window will pop up and in this version control system, we use guess which we need to confirm to get repository, and they're going to have to restart our studio for us.
So, here we are back in our projects and now you'll see in this window here, we have this gift tab. So having setup Version Control to get, we can see these are the files. And here you can click on things files that you can commit to guess which we'll talk a little bit more in a bit, but this just makes it a little bit easier to see what you have. What things have been changed but things haven't been committed. See what the click on this. You would click on Commit and you would have put in a message and I
kind of just keeps track of these were the changes I made. I'm going to commit them to get Hub, write a message. I just scraped his message about what I did, some of the changes and that way people can keep track of each version and you know, make changes as So now that we set up yet, it's important to tell her who you are. So we're going to set up some configuration with a gift and this will be done in the terminal window. So you can do that in our studio by going to tools and click on us Shale and this
brings up, shall we shall make a little bit bigger for everybody. So you'll see that you're in, we created them. I first package directory and you're here and we're going to take out a few commands, which I have also in the vignette and this is we Assume that you have GitHub so I guess I should have breakfast with that to that you'll need a GitHub account. I already have one account for myself. So the first thing is you're going to want to set up the user email so if you have GitHub, this would be the email that's associated with your GitHub
account. So you write get big Global user email and then in quotes, you put your email. So my email for my schedule. And that sucks up the global email for this and then you're also going to want to step up your love life, username and my username for kids hub. Burnout knows who I am. And we could stop here, but we actually want to put this package on to get hug so that we can share with other people. So I'm going to close out of here. And again, we're assuming you have a GitHub account for these next steps, but you're going to want to go into the tools here and
Global options and we are going to click on gets at the end here. And make sure that these are correct. It should be to get past and the ESPN pass. If you've never done late like our student, you get Hub, you're going to want to create an RSA key. I already have a key here, so if you create in our safety, here, you would just press create, and then you would view the public key and you have to copy this. So, you would copy this and Clovis, and then we need to go into our GitHub account. So I'm going to switch from our studio here, into my
web browser, and I am here on my GitHub. And I'm going to move here since my settings. And you go into the SSC gpg. And this is where you would add a new FSH key title, it like work computer home computer Kayla, Mak something, and then you would taste the key in here and this kind of just make sure that things are communicating with each other. If your identification, you set up your username, your email now you have your keys so that should be good. So after you
add the key, which I'm going to go back here to my homepage, we're going to have to set up a repository for our new package. So you would go over here to New. And you want the repository name to be the same name that we created with create. So this would be like my and it is available which is good. You get a description if you want, it's public preferably but I guess if you were doing this just for yourself you could choose, and then you would just treat the Repository. so,
If we go here, we see that we have our repository Creed if you don't have any coat or anything cuz we haven't seen what we have in our our studio session with this get hungry but that is going to be the next stuff. So we come back here for our studio. Yeah, and we have our package created. We've set up who we are and we will set up our GitHub to know that we have this package this repo. So now we want to take whatever we have in our studio session and connected with Target. So
there's a few more commands that we're going to have to do. And we are going to do this in the shallow again, so go into tools shell. And make this a little bit bigger again. And we are going to set up our our remotes so I'm not going to get too much into get cuz that's really a whole nother lecture in and of itself. But the community looking for here are get remote, add origin. My R Studio refreshed on me, okay? Get remote at origin and then we are going to put in the
URL of GitHub repo. We just created. So is https GitHub com? Flash our username. So for me, that Kayla Morel confusing right now and the repo name that we just created the, my first package. And that should be good. And then we're also going to do this gets remotes. That URL origin to get at github.com colon username. And the, my first package. So that sets up our remotes kind of the communication between the repo that we had treated and get Hub and our studio here and we're just going to pull in any changes that may be on our gifts hub.
All right. Love live coding, okay so in theory we should have been able to pull any changes that semester and then we should be able which this probably won't work. Push our changes here up to the GitHub origin Master again So, all right, well, that didn't happen the way I had intended this to happen. But essentially what that's going to do is this get, pull would have pulled down, any changes from GitHub into our, our studio session and then they get pushed would have pushed any changes from our art, studio up to the get help. Just make
sure that things are staying in sync with each other. So anything you're working on locally stays in sync with your GitHub and anything that media people made changes and they merge, then you can pull down and just make sure that things are staying in sink. So that's kind of how to set up to make sure things are communicating with each other. And I think that's kind of like the 15-minute Mark. Totally forgot to set my timer but that's kind of how to set it up and I'll get into what should be in the package. And I think that all kind of calm In the submission process
here. So if we wanted to take a look, so when we first treated that use that create function, this is the shell, that created the description file which is something that we require the name. Save file is something, we are choir and this our directory is where all of your our files would go. And really in our package, for not being our passes about the our file. So that's kind of necessary as well. So if we go, I had posted some links in the possible chats. about
package to Mission with bioconductor one is if you go here to the homepage of file connector, Over here at the developer side because we're developing a package. We have this package guidelines and package submission, package submission. Kind of walks you through how the process works, an intro, what types of packages we we accept, or things like that. And then kind of what is expected of you as an author maintainer. The submission process things are a little bit different for
experiments and then a little bit about the review process because when you submit a package, it gets assigned to one of the core team members and we go through your view, the package for certain things and then some information about what happens after it's accepted and then where you can get additional support when you after the fact that won't go into that one too much. But this package guidelines is kind of interview. This is what I'm looking at as a reviewer it's not an y'all end
all there can be some exceptions, there can be some additions but this is kind of my checklist that I go through because it's it really lays out everything that we would that would make a proper buy a connector package. Because I'm sure there are good packages that don't beat all these requirements and things like that, but this is just a good Baseline. So the first thing that we kind of look at is just in general, making sure that you're using the correct version of buy a conductor in. Are you should be developing on the developers in the bio on dr. So
this might be different if you've been a user bioconductor and you've been using the release Persian, musing the devel version. Just means that these packages can break a little bit more often because you're, you're introducing new features and things like that. So I when you create a new package is going to be on the developer version and this is kind of just making sure the strictness space and time is just making sure you need to run. Rcmd Bill and check on your packages, will be doing that no matter what, because our CMD check has a checklist that
kind of goes through trans requirements. And then we have our own rcmd biosi check. So you run those on the on the Tardis treated with our CMG build and just make sure there's no warnings, no errors and you'll see that as well. I should have pulled up a package submission process, which maybe I'll do if I have time. But in our our, our, our single package Builder, you'll get a build rapport and it'll, it'll run rcmd check and RCMP files to check on your package. Every time you push a change and I'll give you the
printout and we'll let you know if there's anything wrong with your package. And then you can kind of tweak it as need be, so we kind of look for a few things to your file, meaning size if it takes too long to run certain things. So that's kind of just a baseline of the contents of your package. And then this is kind of what we expect inside of the package. So we had talked about This description file. And when we treated, the descriptions, how to treat function makes a very basic. And what if I can pull this up here, makes it very basic description file. So you
can open this up in our studio now are usually at it in a just a text editor, wouldn't that be enough, whatever you you may use. And it just it's a very basic description file. All there's not a lot of meat to it. So what we would expect is, do you have a proper package name? The title should be like, it says, here it should be one line. The versioning is a little different for us. We do in XYZ number, so it should be. I believe 09, can I get the song If I don't look?
09090 is the version that we expect for a first submission package. So that would have to get changed here. I'm sure you would feel an author information. You can add other offers if it's a multi out there, but we only want one maintainer. So it's easy to track down who's responsible for the changes description. This should essentially almost be like an abstract which is kind of what I look for. You want to be descriptive as to what your package does. Why is it different from other packages, what makes it unique licensing? You going to
have to put a license in here. This is just a general blurb, that dust will see us in here and then some other things. So, if we go back to this file here, these are kind of the field here. 1 2 3 4 5, and being a description style and kind of a little bit of information. I really encourage you to take a look at this if you're thinking about submitting a package and what we look for in packages. So all of these things, the depends Imports. Just filled. This is a big one. This is where you're adding packages that your package made depends on your
package, if your package is using functionality from another package, this is where you would let those packages in your description file. So that people know when, you know, they're installing your packages, what other packages are going to be needed. So, that's the description file. The namespace is, when you start documenting, your our files which I really didn't get into, but I can always add more. I'm always available to answer questions or what have you, but this name is when you start documenting, your are functions,
you're going to be exporting your functions. You're going to be importing functions from other packages. So this new space file, just really. It just says, like export the function name in Port from whatever. So we just make sure that things. Good. As far as functioning are like right here. Make sure that you use camel Chaser underscoring and don't use it. Cuz that wind just came past three dispatched from. And so you just import a function, you don't import the whole package to that can take up a lot of you know when you're importing loading your package, it can
take a really long time if you're importing all these packages especially if it's really heavy package, the news file, this is really crucial if you want to be included in like a release information. So this news file has to be it's a pretty specific format. Something like this would go into just in news text file. There's a few places that it can, it can live which is what Lori I believe has done, such a nice job of laying out. Normally you see news files just in the top directory but it can live in other directors as well and it's just kind of
says Hey and this version Like 0990, we submitted to buy open doctor. In this version, we changed X, Y, and Z, and it kind of just gives users and an easier time to track. What's happening in your package, and you can check that by running this commands in our with your, I believe you're after you install your package, you can run this utils news package package and then it should pop up and look, something like this here in this box. And if it does not, then you probably have it for Matt, it incorrectly. I honestly just enjoy
happiness and pasting it into a new style and you can't go wrong with my little ones there. Citation can be included. I don't see this quite as often but this also is in a certain location and you can run this read citation style function on your citation file just to make sure that's formatted properly data is a fake sting. We you can have data in a few different places. You can have them in our experiment Hummer annotation Hub, which there's some documentation
hear about that, you can export the data and in this data directory and there's a certain way that you have to document that type of data and then we also have the raw data data directory in your package. Again there's a certain way to document this as well. Most of the time we won't accept the package and it's not documented because that's kind of like taking information and not giving proper credit where credit is due. So that's a big thing. Is you want to be sure that you document where the data
comes from, how was it created? What is its format things like that? So that's pretty crucial and internal data. I don't, I don't really see a whole lot, but if you have big data files, that's when we really, really stress using like and it's an additional experiment data package. So you can have an additional package. We're like all of your data lives and your your package that you're creating can like utilize that or utilizing our experiment Harbor. Annotation hot is another option or utilizing data that's
already there, which is, it's nice. Cuz then you won't really have to do anything. You could just use other people say. And then package documentation is a big thing. We really like then yes. Cuz then yes walk people through how to use your package, here are some things that we look for in a VIN. Yes, we like an introduction to kind of again, talk people through what makes your package unique, things like that and installation section which would show the user. How do you download your package from bioconductor using strive for a biopsy manager
usage? Just cuz it makes sense is nice. We have our bio C style package that could make your vignette look really nice and a bio C style package, which there's a link up here to buy a few style. I think if I'm not mistaken most of like, if you look at the vignette in RI, And are instances like I used by a few style for this vignette, and it just makes it look really appealing. It uses are nice colors. Things like that. All code must be executable, which might be new, if he's never created a
vignette. You can create chunks of toe that aren't evaluated. If it takes too long or something like that, we really don't like to see that. We like to know that the code is run. That it runs without errors. It's a good way to test to make sure that your code is doing what it's expected to do. Including plots, like you can slot in a vignette, you don't have to like at a static image or anything like that, you can run class in your van yet you can make it look really nice. And then also, we kind of just want a session info at the end. So people know
I think that's easier for like, debugging and things like that to know. What versions of packages and things are being run. And then just make sure what would happen if you would create a vignette directory in here. And that's where all your vignette files with live. But we really only want the vignette file whether that be an R and W or an rmd file and Eddie's static images that you use, there shouldn't be any data files or things like that is being very clean directory. And then the man teaches I think are what most people are used to when they look for help on
certain functions and that's done in the documentation in the our files, if you're using all across the region, And what's nice is that schools has a document function, which when you start adding documentation to your our files, you could just run document. It was I don't have any, I don't have anything in here, but it's it's simply just document and it all create your documents files for you from all of your documentation in your our file and then you could go through and take a look at your man
pages and see, you know, is that usage correct is the definition of things like that. So many pages are are those typical out Pages? You see, when you ask for help on certain functions, we don't like to see, don't test don't run in there. We'd like to make sure that the NEX corded function should have example code. So that way when people look at the help, the Man pages out Pages, they can scroll down to the bottom and run. Examples and know that that code is going to work. If you wrap it, don't test, don't run around
it. Then it's not going to be tested her run when we when we check your package. So we won't know if that code actually works. There are certain sections. Maybe it's it takes too long to run. It's a large example but there's ways to work around that without just slapping. I don't test, don't run around it. So what's nice about the review process is when you submit the package you do have your reviewer there. Like we don't mind answering questions were there to help you. So if you don't understand certain things like just it's a very open Forum, I feel with
your review e, so ask questions that were there for the instructor kind of talked about with the data. That's where you would document things unit test. We want to make sure that your coat is working properly so you can use our unit or test that I really can't get into it here, but there is documentation and would be willing to help you out here, too. But that's just that just again, make sure that your code is worth the way that you would expect it to and it also helps like when we were checking these things on a daily basis, once it's accepted, if a function
changes or something, and I accepted way of fixing bugs and things like that. So tests are really important. I know they can be a pain to, right? And think about what they are very important and then kind of the meat of the package is the Arco. So we try to lay out some things here of what we look for style-wise sintex, why things like that which again everybody's difference in their holding style. So I don't think we can really like Demand that these be met but we highly suggest that this is kind of some things that you think about.
I'm obviously it's really important to not really implementing things from other packages. Like like it's so much easier to just use, you know, don't reinvent the wheel. If there's something that you utilize a check other packages and see if you could just import it and improve it cuts down and duplication and and things like that. So, that's a big thing about her is just being able to utilize other people's code and functions and things like that. Wish, you know, there's there's things here, I won't, I won't
get into too much detail. Adjust things to keep in mind when you're writing our code and then see code does happen and things like that. So yeah that's kind of the submission process. I could try to pull up. This is our issue tracker, which I wonder if I could just pull up really quick. I submitted my bio cset package, so, just to kind of give you an idea without picking on anybody specifically. I figure, I'll just go to my package. See you at submit this and then our issue tracker here. This is kind of where all the action happens, things are checked.
All right. Those are no longer working, but you would get a build rapport. And then, this is kind of where your reviewer can give you some feedback. They post reviews of what can be changed, what? What we suggest to be changed, things like that, and then it's just kind of a back-and-forth. And that's what's really nice about this is, It's, you know, anybody can go and take a look at these. It's between you and your reviewer, and then just kind of feedback and things like that. I do want to make one note at the bottom of the vignette. I talk about
When you contribute a new issue, we're now doing things. Beautiful stairs into the submission process are we just finished up a review, process a little bit. So if you go to that first submission page, the review process here, we're now doing things where you have to set up which may be Lori. Can just talk really quick about this cuz I'm not finding about the jet as opposed to the webhook sure. So when you and then there's a bunch of really good questions that maybe we can. We recently
changed the submission process cuz before there would be this link where you would get a new-build report in the submission process on a virgin bump and it wasn't once you got your package accepted, then we would move it into what would become. What's location on bioconductor at kit. Bassnectar. Org and what we've changed it to is cuz we realize that a lot of people We're having some trouble with get and understanding where to push changes, then after the package was accepted. So now we try to help you understand
the process and being able to push to the two really Caitlin, touchdown that there's two versions of bioconductor. There's the developer version and there's the release version. We always have those active at all times, so we help you to try to understand how to push to the bioconductor official location. Where those would be Propagated to all users and show up on the Pack's Landing Pages for updates. After the submission process is over, this was supposed to be a two-hour Workshop so I wish I could like really
get into the meat and potatoes of a package and like right on our function and show you guys how to check it and stuff, but it's just you know, timing and we can get you some questions and hopefully we can answer some of your questions and if not like the core teams always here to answer questions. I really enjoyed. It is part of it cuz I think this is you know a really great ass back to buy a conductor is that the community can submit their work and things like the first question that we have is actually actually have to do something or can it be used just to store or share,
such as processed are in a 62 associated with a publication? So I think that, which Lori feel free to jump in his class and correct your, but I think that's kind of what is what, distinguishes, our software packages from our experiment data or annotation data packages to the software package. Yeah, we kind of wanted to do something functionality, things like that but the experimenting a package or an annotation package is kind of just that likes its data for annotations or something like that. So you could submit or we have workflow
packages. Why I forgot to mention that was kind of just walked through a workflow of something. So there are different flavors of packages so that I don't think that would be considered a software package which is kind of what I really demonstrated here today is what we would expect in software package. But there are, there is some information on on the submission page in the guideline page about the different types of packages. So if there's something You know that you want in a package, that's not necessarily functionality, I think you should look more towards the data packages.
Can I submit a package that is hosted on another platform such as bitbucket or gitlab? I don't know that one Lori. Currently right now. No currently right now we use get hugged and require a GitHub to submit a package. I know. Lots of people ask about that so we might consider expanding that out in the future but as of right now only not sure if it's later. But could you explain what the main differences between submitting a package to cran and bioconductor personally, I
haven't submitted to cream before I think Lori did but I think, like, Moore's, I think that's kind of, you know, by all conductors. Specialty. Maybe the fact if you're using a lot of file conductor packages and functionality maybe it's more catered towards bile production car cuz you're probably doing similar work but like I used back in my bio stuff days I seem to use a lot more cran packages cuz they seemed like more fast-paced and really biology-based I don't know but that's just my naive thought of
it that I don't know if Lori has any input as far as that goes by analyzing biological resource. We do have some statistical packages and bioconductor as far as the submission process takes already built and we don't do that. And we do this open process of the get repository cuz we want to make sure that it's also building and installing And we do do a fresh build and install every night to make sure that all steps of the process of package are still working properly.
So that would probably be one of the biggest differences and through the submission process crayon. Unless they've made some major changes is a lot more clothes with you and the reviewer and it doesn't offer a lot of dialogue. And part of the reason why we use GitHub and to these issues is for that openness, so that it is completely open to the public. It's open for reference and you can actually have a dialog. Cuz Kayla said, there's always exceptions to things that we look for, or maybe it's still airing, but there is an actual really good reason for it. That
you could have that dialogue with us so that we can work through the process together. How do you balance meeting the development or latest version of our for package development, with the need for a stable, our version for data? So I have, I have two different versions of our on my computer. And I use like Elias has where I have one version, so I'll have like they're released version of our conductor. And there's some magic that happens that points like when I have aliases, I just a like, I don't see 311
and it opens up the correct. Our version with the correct version about the doctor. So there is some setup that you would have to do on your computer, but you can have different versions of our, on your computer, and take some time, and it's a little bit of work, but that way you could just run the article or the are released with the proper bath doctor. I know that's not super clear, but it's, it does take some set up on your computer, but it can be done, which was news to me, when I first became part of the Court, even started bringing things like
that. I thought. But you can have two versions or multiple versions on your computer and we do part of our version process and why we do releases, we do keep past versions of packages per release since the our package can be very tied to our versions and why we do a release at least coincide. With the new Crown released every year so that there would be the availability for reproducibility. You would just have to go back to the version of our and the packages that you were using at that time. And it's also why we
recommend doing the session versions with documentation. So, you know what versions of packages were used at any given time, version dependency burden, can you briefly comment on this? I did follow the interesting Pieces by the staff, and I think it's just I'm not super Knowledgeable about this out of this is my basic understanding, but essentially so Reinventing the wheel. Yes. You don't want to do that because, you know, I mean, you could do that. But why somebody else has done it and done it.
Well, you know, you can utilize that, but there is this balance of you don't want to just utilize a bunch of other people's functions because then your package just turned into. When you go to load it, you're loading and all of these packages and if it can, you know, take a long time on your package at can make your package, you know, it is kind of like a package but they depend on a package and see just so it can get really big really quickly. So I think, you know, you can look at something like Robert had John, where you can, you can
kind of print out Percentage of your dependencies and figure out. If if there's a package that seems to be loading in a lot of dependencies and maybe you're only using one or two of their functions, maybe you don't need that functionality, or maybe that's something that you could improve in your package, that you don't have to depend on that package. But if it's something that you're utilizing a lot of functionality, stomach's kind of something. You can't really bypass on. So that's my basic understanding of it. So it's kind of like a given a taste
like, you know, you don't want to Reinvent other people's work if it you know if it works well and things like that but at the same time you don't want to just create a package, which is just a huge import of other people's packages because I could just be a really foggy package. And so I think I'll definitely take a look at what Robert had put together. I'm during one of the default developer Forums on that kind of can print out your dependencies and how many packages they're bringing wisdom and this and that and you can see maybe you could cut down some of your functionality and
just clean up your package a little bit. So it's, it's a fun game to play when it comes to development. There's definitely a balancing act and the biggest things that we don't want reinvented because most of the time there was a lot of thought, process to go into it and bioconductor already would be like the import functions or a data structure for a particular class. Would you like to see the interoperability between packages as well and to allow users to use? Not only your package but other packages. So the biggest things to watch out for that we wouldn't
recommend Reinventing would be those Imports in class structures. I did see in the chat, people are asking, I'm trying to see if I can pull up the developer Forum that was talked about but you can also I know on the devel slack there was some also some discussion probably in the developer Forum Channel about and we can find that and post that the chat will be available after after this session ends too. So we'll make sure that we get a LinkedIn there. Good ideas for a couple times and it's it's interesting to think about what is the
general rule in writing a unit test? Do we have to write unit tests for every function? I would say? Yeah. So you can take a look at like test coverage of your package and you can run some things to see how, well your package is being tested compared to how much code you have and things like that. So like my bio cset package has a lot of trust in it and it runs really quickly but when I ran the coverage I think I don't think it's more than likely these 78% tested, which
is something that I can work on. So, ideally yeah, you would want it's just ensure that your functions are working properly and that they don't break. And when they do break, it's easy to find. So it takes a lot of work though to get Especially if it's a very intense pre-packaged. It's it's, it's tough to write that many units. Do you have to be very smart about it, but I'm definitely no expert when it comes to writing tests. But ideally, yeah, we don't want to seem just so, you know, some, I've seen some submissions where, you know, they just they read a
test vial and they just right auto test that two plus two equals four. Like, that's not testing your code, that's there in a test in there and yes, it's going to pass. But like, when we ask for unit test, we want your functions to be tested properly and things like that. So I would say shoot for as much as you can, come get two mans. Look difficult for me can such settings, be configured by our studio button. So, I don't know a lot about art studio buttons, and setting. Those kinds of things up. I just run
our from my terminal basically so that's something that I'd have to look into but I'm sure some people have set things up in our studio that I'm sure could shed a little light on that. So I'm not going to say yes or no to that just cuz I don't use rstudio. India, an expert on the call, who does know how to use our studio. That could raise their hand and share their screen. Tattooed technologically challenging the holes. Once you have it setup, will then you can Infuse different buttons but
There's a couple people I don't, I don't know. I don't know if I have to do anything or for you. I see the race yet so I don't know. Maybe while that's happening, I'll just interject in that. I can't share my screen right now because I'm on my iPad, but I actually use you the Alaskan state tree for a graphical stuff which featured than than our studio. You can do pretty much everything in it and then it without having to learn all this stuff with the
word either. Yeah, I think, I think, at least, for myself, I was one of those, like, I only look at them when I need to set up a package, and then just kind of use the ones that I, I know off hand, push, and pull and such, but yeah, I think, if we can simplify that for people, I think they'd be very helpful. There are buttons in our studio for doing pushes and commits and even branching in the latest version. Yeah, so like yours here is my studio session. if I come down here, there's a tab that says get oh wait
actually if you go to Assist tools, Version Control. There's like a project, you won't see all this stuff. If you haven't set it up yet, and it should Auto detect if it's going to get repository. But if you click project setup, just change your version control system to get. And then down here. So if I make a change to this file and save it, it'll show me my Aunt unstaged commits and you can click the box and click commit. And then you see the pop up? That'll show you this pop up. You can ride.
You commit message and click it and then push and pull. Those are really simple and if you don't have a SSH key pair set up, it'll prompt you for password. I just posted a link to in the chat Forum using our studio. I will say that we can make sure that we take these pills questions and put them in the chat. So that you all have at least some sort of answer in the chat, cuz the chat will be visible. And I think visible from the public forum and you could access the chat after this closes. And I know the the lunch with the core
team started, so I'm sure Kayla would be welcome to take more questions at that too. If there was anything really pressing that you wanted a in-person? Yeah. Yep I'll be on the the lunch at noon. So I'm just going to run and grab some water and then I'll be back on for that. So any other questions on? But I'll make sure I dress the ones in the in the pool there. And just thank you guys for hopping on and I hope to see some new developers submitting their packages and I can just say, just don't be intimidated. Just go for it and Review process is not scary and I
think it's very educational. Many people have commented back. You know, just thanks for taking your time. Thanks for knocking me through it, and things like that. And that's what we're here for. So, I would say, just go for it and see what happens. Thanks, everyone,
Купить этот доклад
Купить это видео
ConferenceCast.tv — архив видеозаписей докладов и конференций.
С этим сервисом вы можете найти интересные лекции специально для вас!