The Structure of Paclets

Hello, everyone. Hi. Thanks for coming. Connor Gray is scheduled to give this talk. Unfortunately he is ill and cannot give it. Luckily, however, we have a recording of a talk, essentially the same topic that he gave about a month ago. So what we're going to do is we're going to play that recording. I'll, I'll be here and people have questions. I'll pause the video and try to answer them. We'll do it like that, sort of as if, as if I was giving the talk. Except Connor will be talking. So I think we can have, you know, feel free to interrupt and ask questions. I'll just pause the video and answer them myself. The video is going to be 45 minutes long. Just going to run as a continuous block over the next two talk sections.

Hello, everyone, my name is Connor Gray and welcome to the next installment in our R and D Livestream series. Today I have the opportunity to talk to all of you about Wolfram Packlets. So what are Wolfram Packlets? Well, packlets are our technology for bundling up code and data that gets distributed in the Wolfram system. So when you, you know, a lot of functionality in that's part of the system is actually broken up into, into these things that we call packlets. And so they're a way that code and other things can be shared and distributed in a modular way. So they're a very powerful way of creating kind of collections of content that you might want to preserve or share with your colleagues or with other users or publicly. They are an archive format for basically everything that you can extend the Wolfram system with. So as I was saying, packlets add new functionality to the Wolfram language. That's their basic function. The most common thing that by far that packlets contain is Wolfram language source code. And that comes in the file in the form of WL or M files. But in addition to source code, packlets can also contain things that add new features to the front end, like palette menu items or style sheets. So packlets are a generic way of storing any kind of content that the Wolfram system can discover and kind of add in to various places throughout the system. Auto completions are also something that are stored in packlets. As I mentioned, a lot of the built in functionality in Wolfram system, when we who work on the Wolfram language every day want to add something new to the system, that's a new area of functionality. Oftentimes that will be a dedicated packlet. A few versions ago, I believe it was 12.1, we started opening up the Packlet system so that users of the Wolfram language could create their own packlets in an easier way and use them to distribute their content. So these days it's very easy to inspect all the packlets that make up an active Wolfram language installation. There's a function just called Packlet Find and if we go ahead and run it, actually this returns hundreds and hundreds of packlets. So I'm just going to show you the first 10 just to give you an idea. But you can see there's packlets for things like classifiers for specific kinds of content. Lots of the chemistry functionalities in a packlet, chat tools, benchmarking, all kinds of stuff take are developed in the form of a packlet that goes into the base installation of the Wolfram language. Now, I mentioned that we, you know, in 12.1 we first added the basic functionality for users to create and interact with packlets. Over the subsequent versions, we've been fleshing out our technology for authoring and building and kind of going through the development process of working with packlets. In Wolfram language version 13, we added a bunch of new tools, notably the Documentation Tools package, which is a tool similar in form to what we use Wolfram Research to author the documentation that you can browse in the system. So this is a tool that enables anyone who wants to create a packlet to write their own documentation pages that can be just as full featured as those that are built into the language. In addition to documentation tools, there's also a the aptly named Packlet Tools package, which contains some functionality for for building documentation, building packlets and inspecting the content that is in packlets. And this is intended to be used by people who are interested in developing their own packlets and functionality that is built on top of packlets. Also new, just recently announced a few months ago and in its first public release, is the Wolfram Packlet repository. This is in the style of our existing repositories, like the function repository or the data repository, but it's the packet repository and it's a place where, excuse me, where anyone can upload a packlet that they want to share with the rest of the Wolfram language community. The great thing about the packlet repository is that just like the other packlets or, sorry, the other repositories that we have, any content that's in the packlet repository can be easily installed by any other user of the Wolfram language. Just to give you an example, I'll take one of the random packlets off the front page. Let's say Wolfram Packlet CI CD Pack repository has what we call a shingle page. It's kind of a landing page. It's where you get to say hello and introduce your packlet to people who want to browse for interesting packlets. Importantly, it also has this packlet install command on it. If I want to try out this CI CD packlet, all I have to do is click copy this install command and go back over to my Wolfram Language session and run that. It actually goes ahead and installs that packlet for me right on the spot. It's a very easy and powerful way of getting your content that you want to share with others as easily as possible into other people's hands. So we're really happy to have the pack repository and like I said, it's relatively new, but we're looking forward to people who want to develop packlets, hopefully uploading their packlets there and sharing them with the rest of the community. So that's a bit of a high level overview of what packlets are and what they're useful for. The rest of this talk is kind of going to be structured as kind of a deep dive into what goes into packlets and how packlets work with the intention that people who want to develop packlets can kind of learn about how you actually do that. So the first thing I'll talk about is, well, we want to make a packlet. How do we do that? So, as I mentioned, there's this Packlet Tools collection of functionality that you can go ahead and load in your Wolfram Language session. And this gives you a function called Create Packlet. So this is just a helper that will create the initial content for a new packlet. Createpacklet takes two arguments, takes the name of your packlet, and it takes the directory where you want to create that new packlet. Now, you might notice that this packlet is actually made up of two components. I'll note that this is not actually a file path. This is the identifier for the packlet. And the first component is made up of what we call the publisher id. This identifies an individual organization who, who is kind of the authority for this packlet. They're the publisher. They take responsibility for what's in it. The second is just what we call the base name. This is the descriptive name for what the packlet's actually about. So if you were writing a packlet that was all about chemistry, say this, this would be chemistry. So I can go ahead and run this code and we're going to See that it's going to create a new set of files on my desktop. You can see this directory just popped up over here. I can go ahead and just double check, confirm with the system what it thinks the location of that packlet is. Just make sure that file path looks right and we'll go ahead and open up a file browser just so we can poke in that. So what did this create? Well, it created a couple of things. It created a packletinfo wl file. Now the packletinfo wl file is technically, it's the only file on a packlet that's actually required to exist. It's the metadata that describes that this directory is a packlet. And it includes things like if I just preview this file here, it's got a packlet object which is kind of the Wolfram language symbolic representation of what's in a packlet. And we can see in here it's got the name that I specified to create packlet and it's also got the publisher ID and various other things that I'll go into detail in a moment. So created that packlet info file and it created some other things that we're going to have a look at. So.

Right.

It's basically, I was just saying, but it created this packlet info file in here. And yeah, that's the description of what's in the packlet.

Just for a second I just kind of want to point something out. So kind of showing here, this create packlet function is like the in language method, a convenience method for, for creating a directory that has kind of the structure of a typical packlet and a packet info file, sort of a stub file that you could complete yourself. So that's one very convenient way of creating a packlet. Another way to create a packlet is just to go to some directory and you know, create a packet info file yourself, edit it and you know, put whatever, you know, essentially by hand. But the third way, in case people might be confused, if you're talking about submitting something to the packet repository, there's a workflow that involves this pack, this resource definition notebook. You know, on the, on the file menu, this file open. Where is that on the menu? The file, new repository item, you know, packlet or something. And that will open up a notebook that kind of walks you through this. So you. So that's a perfectly good way to do things. Highly recommended. Create packlet is a little more low level, you know, in the language. You can just create this basic structure, which is quite convenient because it Gets you going quickly.

Yeah.

Yeah, you, you missed the top line, you have to say, needs packlet tools. It's. It's in a context.

Yeah.

Absolutely. Create packlet. Just create some. Oh, I'm sorry, I'm sorry. That's a good point. The question was, does this run on the cloud? For example, can you call Create packlet? And the answer is yes. Create package just creates a file structure and things. Packlets do work in the cloud as well. So there's some subtleties about using packets in the cloud, which is not really going to get into here. But yes, Create packet work perfectly fine in the cloud. Right, I'll let Connor continue. Yeah. Single manipulate, meaning a single notebook that has one manipulator in it, is. Is a brief, pretty small thing. And it's not. You could certainly make a packet for that. And people. You could just tell people, you make a packet, you upload to the repository. I mean, the convenient thing about making a packet for that and put it on the packet repository is that then you can just tell people, just type packet install, you know, blah, and you'll get my notebook. Right. The thing is, a notebook like that, then they have to go and open it. And how do they open your notebook? They would have to like, drill down into the package, find the packlet which is installed in some kind of obscure spot, and open it. If you wanted, you could make a palette. So that would show up in the menu as soon as the packet's installed. If you had made this thing as a palette, then it would show up in the menu. Maybe that's not quite what you want to make a whole palette out of just one notebook. A single notebook is maybe the sort of thing that you just upload and you, you know, to some URL and you tell people, here, download this notebook and open it. If it's in a packlet. There's no obvious way that your users would then open your notebook. You see what I'm saying?

To have a certain process flow and I wanted to control that.

So the question was about, can I do this like a packlet in a palette? A palette and packlet. Right. That's going to be in the cloud. And the answer to that is no. Unfortunately.

That name, like I mentioned, that we passed to CreatePacklet is the first field in that metadata info that I'll just mention. Actually, this. This name is what shows up. I mean, this is like the display name for your packlet. It's what shows up on the packlet repository. You can see, when I was back Here on the Packlet repository website, every packlet has a name, you know, Wolfram, slash, something, or me. The next field is just this Publisher ID field. This is, like I said, this is the authority. This is kind of the person who owns this. Many people do. The name will be different for each packlet, but the Publisher ID will be the same because they're all your packlet. And just to see. So that Publisher ID is actually, it's part of our Wolfram Resource system. So if you've ever published something to the Wolfram Function repository or one of our other repositories, you'll have a Publisher id. If you don't, there's an online form where you can just go ahead and register your Publisher id. It's very easy. But once you've done that inside the Wolfram language session, if you're signed in, dollar Publisher ID is going to be going to be that same value. If you're not signed in, just use Cloud Connect to go ahead and connect. Next up is a version field in the Packlet info. So this just distinguishes different releases of your packlet. So you release initial version of your packlet that might be some, some small version number like this. Maybe you go straight to publishing a 1.0 version. That's, that's up to the author to choose. But as you make changes to your packlet, you'll, you'll increment one of these version number components as appropriate for the size of the change that you made. So version is just a way to signal to users of your packlet that there's, you know, new content available and how different that new, that new version of your packlet might be from existing versions. As a note, we strongly recommend that Packlet authors adhere to the Semantic Versioning standard. This is mentioned in the Packlet Repository guidelines, which you can find on the Packlet repository website. But semantic versioning is just a convention that makes the numbers and a version number significant to users or interpretable. So that's the version field. Next up is the Wolfram version field. So this, this is the thing that declares what versions of the Wolfram language your packlet is compatible with. So let's say you write a packlet first in wolfram language version 13.0. You might declare that your Wolfram language version is, well, 13.0. But let's say a little while later we've released wolfram language version 13.1, and you decide there's a new function that's in wolfram language version 13.1 that you really want to use in your packlet. That's a. Okay. You just have to remember to be sure to update the Wolfram version field of your packlet to reflect that you're using content, you know, new functionality from wolfram language version 13.1. This is a way of signaling to users of your packlet whether or not they can actually use it or not. You know, if somebody's running Wolfram language 12.3 and you've declared, you know that you can only it's only compatible with 13.1, that'll let those people know that they're not able to use your packlet without upgrading, which is important because if they were able to use it, some things might go wrong if there were functions that didn't exist in the older version that you were using in your code. So that's Wolfram version. So so far, all the fields we looked at were kind of. They're kind of metadata about the pack, but they're not really the meat of the packlet. The extensions are where we really get into kind of real content. That's the thing you're actually trying to distribute as part of your packlet. As I mentioned, the purpose of packlets, the reason we have this technology is that they are, excuse me, they are a way of extending the Wolfram language with new content. I mentioned primarily that new content comes in the form of code, but other things are allowed as well. So anything that can be in a packlet that extends WULF language with new content is something that's declared in the extensions field. So I mentioned that primarily it's code that's the kernel extension. So if you have code that you want to add to the Wolfram system, you create a packlet that has.

Okay, so the question was, can you write a packlet now that's listed as being compatible Back to version 10 or even older? So the answer to this question is a little complicated. The packet manager went underwent a major change in version 12.1, where we. All the packet manager functions used to be in the packet manager context. They were sort of hidden from users 12.1. We put them in the system context, documented them, changed their names for a few of them, kind of did a little bit of a redesign. And so 12.1 is kind of a mark for the new packet manager. Another thing was that this new syntax of a packet info file that has this packet object expression is also new. In 12.1, the old packet info file just had packet open bracket, no association, no packet object. And so if you write up and what we did is we what we've done with the packet repositories, we have patched the packet manager itself via a packet update back to 12.1, so that everyone with 12.1 and later understands this new style of packlet and also knows about the Wolfram language packlet repository. So trying to. So the packlet manager works and packlets, essentially everything's being said here will work perfectly fine going back to, you know, I don't know, version 8 or something, but if you wanted to make a packet compatible that far back, you would have to write the packet info file in the old style, which is trivially different from the new style, but it is a little different. Packets on the packet repository only use the new style. So if you want to put something on the Packet repository, only 12.1 and later users would be able to use it. That answer your question? We're hoping that eventually, with the march of time, this 12.1 transition becomes ancient history and no one's really too concerned about compatibility. Back before then.

You mean?

Right, but the thing is that when you talk about package, you're essentially talking about the format of a, of a single M file, you know, begin package, end package, all that sort of thing, right? Or are you just using a more general term per package? I mean, Okay, right, but you could take that type of package, an old package, and throw in a packet info file and you'd be done, right? You just throw in a packet info file and make it a packet. Packet's in the repository have to have a more stylized, you know, in terms of the context names and the packages and things like that.

The kernel extension, the kernel name, simply, it just means that what you're adding is kind of extending the language in some way. You're adding new functions to it. You might just think of this as, you know, this, this name is. It has a certain history. That is why it is what it is, but it just means code, basically. Now, in this extension it takes some options. The first is the root option. This just specifies what file directory the files associated with this extension are in. Because we call it kernel by convention. The kernel extension is going to be stored in directory called kernel. Excuse me, Sorry, Just drink some water real quick. Sorry about that. Right, so you know, that's just the directory that those files can be stored in. Next up is the context option. So this is where the Wolfram language context for the package that you're writing is declared. And what I mean by context is anything that you can pass to the Wolfram language Get or needs functions. So you saw in the code I ran earlier that I evaluated needs of packlet tools. Well, the reason I can do that is that there's actually a packlet in the system called packletools that declares a kernel extension, and that kernel extension specifies a context called packletools. So that's how the system knows when I evaluate needs of packlet Tools where it should find the source code associated with that. And just to peek under the hood a little bit, the way that actually works is that there's a function in the language called find file, and if you give it a context, it goes off and tries to find what file it should load when you do needs on that context. And we can actually see here that it's going and finding. I have packlet tools version 0.0.12 installed, and it has a kernel sub subdirectory, and inside that subdirectory there is a packlett Tools WL file. So that's the actual file that gets loaded when you evaluate needs packletools. And just like for packletools as for any custom packlets you might have, it's the same process when you declare a context in the kernel extension, that makes that context known to find file and needs and all and related functions. Right? And so just to be clear, the context that you specify, by default, it's going to look for a file that has the same name as the last component in the context. I happen to spell it out explicitly here using this alternate form where a context is mapped directly to a file name. But you could just as easily just say context arrow the context itself. But that's, that's how the system knows what file is associated with that context. So just to illustrate, in the previous step, I created this packlet. So this packlet exists. It's on my, my desktop right now. But at the moment, the Wolfram language doesn't actually know that it exists. And the way I can prove that is if I do needs of. Oh, oh, maybe I did load it in earlier step. Well, okay, I guess I did load it. But by default, when you use Create Packlet, it creates some files on your system, but it doesn't, it doesn't actually load your packlet into the Wolfram language. So I've got a fresh session here. Oh, you know what I think, I think I have a previous version of this packlet installed from the last time I gave this, this presentation at the Wolfram Summer School a few months ago. So that's why that's not doing what I expect. I'm expecting this to error. Let's just try this one more time, right? There we go. Okay, so now it's, now it's working as I expect, right? So I created this packlet so my desktop, but the system doesn't know about it unless I tell it about it. So if I try to do needs of that context, the system says, hey, you know, I don't know anything about this context. So if I want to tell the system about my packlet, one way to do that is a function called packlet directory load, which, which I just give it the file path to my directory or to my packlet. Oh, and okay, well that's not defined, but I know that path. So, right. So if I do packet directory load of that file path, now system is telling me, okay, this file path has been added to the list of known packlets. And now if I run needs of my packlet, I don't get an error that returns nothing. That just means it was loaded successfully. And if I use find file, it's going to tell me the location of that file that it's loading for that context. And all of that again happens because I've declared that context field in the packet info file. So the system knows about my packlet and the packlet tells the system about this context that it, that it has. Okay.

Interrupting whenever I want. I just wanted to point out he talked about the packet directory load function. It's kind of a developer function that most people won't use. The point he's making here is that the packet manager knows about a bunch of locations where packets might reside. It knows about the Wolfram language layout, for example, and it knows about a directory that we call the local repository. It's often your user based directory area. So the packet manager automatically knows about packets in these areas. But if you create a packlet, just some random spot on your hard drive, just like he just did with that create packet function and you've got some files in there and you're like, okay, now I want to use this packet, right? I want to see, I want to run its code, I want to test it. Maybe I'm working in some IDE and I built the packet structure. Now I want to run the code in this packlet. You need to tell the packet manager, you know, look here as well to find packlets. And so packet directory load is a function that does that. It essentially adds this directory to the list of locations that the packet manager looks for packlets. It's Kind of like in the old days when you work with $path, it's like append to $path some directory, right? You're telling the system about a next replace in which you might find packlets. It's not something that users of packlets think about because packets get installed into places that are already known to the packlet manager. But if you're developing a packlet and you've got it in some random development directory on your hard drive, you'll need to use packet directory load to tell the system to look there. So the question is that people are noticing, what's this, this double underscore here I'm seeing in this directory path, and in other. And then I see slash names. And then in context, it's about the double underscore. Packlet names are just a string of characters. And for the Wolfram packlet repository, we require that they have a certain stylized form, publisher ID slash, base name. And that does not mean a directory that does not map to like a subdirectory structure. It's just a string of characters that have a particular stylized form. Now, when the packet manager creates a dot packet file or installs that dot packet file into a, you know, unpacks it into a directory, the question is what directory name should it use? Or. Or the actual file name for the dot packlet file can't have a slash in it, right? That's a directory separator. So what the packet manager does the convention is that we turn slashes into double underscores. So in a sense, when a packlet name that has a slash in it has to be represented as a directory or a file name, it gets converted into double underscore. It's not something that you have to do yourself. You know, normally you couldn't care less what the actual directory name is. For a packlet, it can be any directory name. But when the packet manager creates a packlet file and installs a packlet file to, you know, create a directory for the installation, it turns the slash into double underscore. And the backtick is for context, right? A packet name typically maps to a context. You know, the, the back. The slash becomes a backtick. That's just a convention as well. I hope that long answer it's not more confusing. Yeah, the thing about the devil underscores, it's not something you have to think about, because when you create a packlet, you can make it in any directory you want. You can call directory anything you want. When you build a packet, which we'll see Connor do later. It creates a dot packlet file and if, if your packet name has a slash in it, nothing to do with its directory location, it just the packet name happens to have a slash in it. When you build the packet into a packet file, the packet file will have double underscore in it in place of the slash, because it can't have a slash in a file name. See, it's not really something you have to think about.

Ok, so that's, that's kernel, that's, that's extending the system with new code. But like I said, packets can contain things other than just code. The other most common thing that they typically contain is documentation and especially packlets that are authored by external folks, you know, folks who don't work on the Wolfram language. These are, you know, documentation is very important for making sure that people know how to use your package. And I'll go through how to, how to author documentation now. So by default a new packet contains a documentation directory, but there's not really anything in that directory yet. So if we want to add new documentation, we need to use that Documentation Tools tool that I mentioned earlier. Now, Documentation Tools is built into the Wolfram language, like I said, starting in wolfram language version 13 and newer. And if you go into the System Palettes menu, you can open it up. There it is. So if I go ahead and click on that, it's going to open up the palette and there it is. So this is the Documentation Tools palette. This is all the functionality you need to create new documentation. Now I'm going to have to select here, I'm going to have to tell the palette about which packlet I want to add new content to. So I'm going to go ahead and click that Add Packlet button and select my Packlet directory and it's going to ask me, just confirm some information about it, make sure I've got the right packlet that all looks right. I'm going to go ahead and click ok. And now you can see it's my packlet that's selected. And you can also see that it's created some new directories down here. Now, these are the default directories for the three most common types of documentation, which are symbol reference pages or function pages, tutorials and guide pages. Now I'm going to briefly walk you through how you create a basic function reference page. So the palette contains all the things you need to make new documentation. All I have to do to make a new page is just hit new function page and it's going to ask me to pick a name. Well, I'm just going to say say hello and it's going to open up a new little notebook. And this notebook is where I can author my documentation. So these notebooks are actually what they're very. Work on when we're writing new documentation. They have a kind of the name of the symbol that's being documented. This is what we call the usage message. So this is kind of a brief one line description of what your function does. So I happen to know that this say hello function is going to, well, it's going to greet people. So it takes a name parameter and I'm going to say that say hello prints a greeting message saying hello to the named person. So that's a basic piece of documentation. Now a couple of things. This name here, because it represents a function parameter, we often don't want to style it just as plain text. We want to style it kind of in a, in a, in a italicized way that it kind of represents something that can be any value. And the way we do that is this template input button. So that just turns that, that parameter into, into a template argument. And if I go ahead and click that, it asks me if I want to make that a link or just format it. Well, I don't want to link anything, so I'm just gonna say format. And I'm gonna do that not only in the parameter, but also where I reference the parameter in the documentation message. So I'll go ahead and hit template input again, say I just want to format that. And now you can see that name is kind of appropriately styled for being a function parameter. So that's the basic usage message. You can do more complicated things in these notebooks. You can link to related tutorials or notes. You can put in arbitrary links to other web pages or other functions and things in the system, or not functions, but other other other things in the system. You can add in links to other symbols and you can add in links to other guide pages. You can also include examples for your functions. So you'll want to include the examples. Initialization. This has been filled out by default, but you can put other code in here if your packlet's more complicated to load. This is just something that gets run for every example and then you can write a basic example. So I might say say oh, sorry, I want to specify that I want to be putting in text. So I'll just go ahead and use the insert text button to insert some plain text and I'll say say hello, can be used to print a greeting. That's my textual description. And then I'll just say hello of I don't know, $username. Okay, so that's my example. Now one thing I forgot to mention, but is important to realize is that the Create packlet function, it actually generates a WL file for you as well. This is just a kind of placeholder that you'd fill in with whatever the content of your packlet's gonna be. That placeholder happens to define a bit of code in our standard package format convention. So it begins with a begin package statement and, and kind of has a declaration of all the public symbols in that package. And it provides a very basic definition for this placeholder say hello function. And, and because it does that, I can actually evaluate this example here. And it works. But that's not magic. It's just Create packlet creating some placeholder content. You're, you know, you're expected to change what's in this file to suit the package that you want to write. Ok, so cool. So now I have a very basic function page. And you'll notice right off the bat this obviously looks pretty different from the documentation you see in the system. And that's because as it says up here, this is actually a function page authoring notebook documentation. Notebooks go through a build processing step to actually transform them into the kind of final pretty form that they, that they have in the. In a finished packlet. So we can build documentation as well. The packlet tools package that I mentioned actually has functionality for, for building documentation in it. It's got this packlet documentation build function. If I go ahead and. Excuse me, I'm going to just set this so I can use it. Okay. If I go ahead and run this packet documentation build function, pointing it at my packlet, I'm going to call your attention to the files over here on the right because it's actually going to produce some new files which are the built documentation, so. Oh yeah, well, I restarted my system earlier because of that problem, so I'm gonna have to load packletools again. That's pretty simple. So there we go. It's loading packletools. And now I, and I forgot to evaluate that again. Okay, all right, so now it's going to load packlet tools. We get some warnings here because we haven't included some version metadata in our file. That's okay. But you can see that it's actually created this new build directory over here inside of our packlet. And this build directory contains a layout of files that's basically identical to our source packlet. But because we've only asked to build documentation, it's only put the documentation in here. You can see it's also actually created some new files. There are these search index files. These are just metadata that allows efficient searching when you have this packlet installed and you want to search for something in it at the documentation center. But we really. Excuse me. What we really care about is the built version of that page we just authored. So if I go ahead and open this up, pop up over here. So, yeah, so this is our built page. Obviously it's got all the same content as in our author notebook, but it's styled just like the documentation that's in the.

We're not. I can see that we're not going to be able to. We don't have enough time to see the entire rest of this video. So what I. I think at some moment when he finishes discussing the current topic, I'm going to pause it, I'm going to kind of scan ahead, maybe jump through some of the documentation authoring stuff, because I'm not exactly sure what he talks about at the end. I'm sure he's got some more important points about packlets and packet development. I want to make sure we get to. So I'll probably maybe skim over some of this discussion about documentation authoring. I'll let him. I'll let him talk now to finish the point.

Language that you, I'm sure, all familiar with. So, you know, the point here being that these are the same tools that we use to author documentation every day and they're available to users and anyone can use them to, to offer their own documentation. So that's building documentation. So what if I want to actually share the packet that I've been authoring with other folks? The way I do that is using the packlet build function. So I just use the packlet documentation build function to build only the documentation. Packlet Build actually goes a step farther and, and builds all of the content that's in my packlet, not just the documentation, but it copies in the packlet info file and my source files as well, and any other content that I might have in my packlet. Now, importantly, Packlet Build, you'll notice it doesn't copy in this resource definition notebook up here, which I'll get to a little later describing what that is. But suffice it to say, this notebook is not considered part of my packlet and packlet Build knows that. So it doesn't actually Copy it into the build directory, which is exactly what we want. And likewise, you know, it's common for you might have a readme file in your packlet, you might have some private scripts, you might have documentation that you don't want to share with other people. That's all fine. Paklet build knows not to include any files that aren't declared in your packlet info file. So because we don't have any extension in our packlet info file that references this resource definition notebook Packlet build knows not to include it. So that's packlet build. Now you can see packlet build. In addition to creating these other files in here, it's also created something entirely new, which is this packlet file. This is actually the an archive format of the packlet. It's got all the packlet content in it. So this is the file that you'd want to share with people you work with or friends or colleagues who want to try out your packlet. So you could email it to them if you want. These days, we'd probably encourage you to upload it to the packlet repository and let everyone benefit from it. But the choice is yours. So once you have a packlet, a packlet file, and you want to actually use it in the wulf language, maybe you sent it to somebody and they want to know how to use it, it's real simple. There's a packlet install command, and if you run that and pass it the file path to to that packlet file, it goes ahead and installs it in your system. And now if I quit my session, so I'm starting over fresh, but I asked the system, where is Connor Gray backtick my packlet? It actually still knows about my packlet because I've installed it. So when you install a packlet, that's making it persistently available and that packlet will stay around until you uninstall it and you can see it's placed it in an appropriate directory on my system and there it is. So if I decide maybe I'm done with this packlet, or maybe it's an older version I want to get rid of, you just say packlet uninstall. And now if you try to load it, system doesn't know about it anymore, but you know you can uninstall and install as you wish. Oh, and I should mention importantly, let me go ahead and install this again. So I'm going to packlet install and I'm just going to give it the path to here, I'll just browse to it, give it that packletfile path. Gonna run that. So I've, I've installed it again because that's one thing I forgot to demo. So when you have an installed packlet, not only can you load its code, you can also view its documentation in the documentation center. So if I search for that say hello function, the. Well, the system should be able to find it. Let me see. Did I. Hmm. Well, let me just see. If I say.

We're starting to figure out why say hello docket, I just want to kind of summarize. So what he did was he used Create Packer to create this package directory structure. He added some files in it, he authored some docs, and then you have to build a packlet. You have to essentially, you know, this, this directory has a bunch of junk in it, maybe things that don't really belong in the distributable packlet. Plus, the documentation files that you author have to be themselves built, have to run through this processing stage to get turned into their final form. And so packlet Build does both of these things. Creates a separate directory inside your directory that has the built form of the packlet, which will have the built docs. It will have extraneous files that you probably, you know, your dot GET directory or things like that, whatever, are not in this packlet, this build packet directory. And then create build pack that also creates a dot packet file, which is just essentially a zip archive of this packet directory. And you can. That's the thing that you would upload to the packet repository. That's the thing that you can give to colleagues, whatever. And, you know, you've seen packlet install, where you type packet install and you give out just the name of a packlet. Well, that's when the packet is on some known packlet site like the Wolfram Packlet repository. But you can also call packlet install just on a pack file, and it will install that. So if you just give a packlet file to your colleague, they just type packlet install and give the path to the file and it gets installed. I think I'm going to skip ahead here and see what he's doing in the rest of this. Okay, so Joel's asking a question that's really more or less about kind of an internal feature of the packet system, which is that you can declare symbols in your packlet to be auto loading, so that the first time the user evaluates one of these symbols, that's when your packet loads. This is a feature we use for a lot of internal Functions where we don't have to preload all the code at startup. We wait until the first time you type the name of a function and then at that instant the packlet gets loaded, all the code for the packlet gets loaded. But the answer to that question is that there is a non trivial cost to auto load symbols. It's very small, but it's not trivial. I don't think we're getting close to any kind of limit for that, but I wouldn't. If outside users or internal users pile another 10,000 symbols into the autoload set, that's probably going to be a problem. That would not work. Yes, and this is, this is a reason why we don't document the auto load feature for packlets. That, that, right. You know, users type, you know, you type foo, right? And that's got a definition that says execution of foo should load packlet X. And if there's a packet Y that also has a symbol foo, one of those two guys is going to win, you know, and only one. No, no, because what, what you're typing is just the short name of the symbol. And this is really not relevant for. This feature is really not relevant for user packlets. Okay, we'll just play it. He's going to talk about Packard repository things, some of the same stuff that we've seen in other talks. I'm just going to let it play more or less until, well, the time's up essentially. Actually, yeah, you know what the time is. The time is really up. So let's just do questions now. Yeah.

Is the primary thing.

Okay, so application packages are just, you know, a directory that contains a bunch of M files and maybe other things. And the only way that you can load code from an old style application is if that directory is on dollar path. Right. And so those things continue to work fine, but they just don't have any of the features that packlets have. And so, but if you give me an old style package, I can probably in like two minutes write a really short packet info file and throw it in there. And now you've got a packet, right. It's really just the presence of this packet info file that bestows this packet ness on a directory, you know, so.

In terms of the. Versions of those, like is that something that's going to be.

Okay, so the question was about paid versions of applications. Are we going to be supporting that? And we absolutely want to support paid packlets. The Wolfram language packlet repository is not set up for that at the moment. And so that is not on our immediate radar for paid packlets, but we absolutely want to support that. There's various issues that have to be tackled to make that work. It's on the short to midterm list for the packet repository. Yeah, No, no, I mean, there's a. Oh, you're talking about. On our website, we have a set of things maybe called sort of add ons. Yeah, yeah.

We.

We do sell a bunch of packages that we sometimes call add ons that are commercial things. I don't think any of those are distributed as packlets in their current form. Many of them have their own installers and things like that. Well, I'm not. I haven't looked at those for a long time. And some of those things are. I'm sure that many of them could easily become packlets. Some of them are more standalone things that maybe aren't really designed to sort of these subsumed, you know, subsidiary to the Wolfram system. That means they're like, I launched this thing. I'm not exactly sure what's in there and. But I expect that many of them could become packlets. Yeah, yeah. Joel. Yes. Yes. Joel's asking whether the Wolfman language Packard repository is one of the default known packlet sites for your system and answer, that is yes. So that's what. That's why you can just type packlet install and give a name from something that's on the packlet repository and it finds it. If you remove the Wolfram packet, if you do packlet site remove, you know, wolf and packet repository, then it won't be on your set. So don't do that. If you don't manually remove it, it's there. If you do manually remove it, you'll have to manually add it back. But people probably are not going to be removing the important packet sites when they're set.