 Yes, so I want to talk to you guys today about part of the Elixir ecosystem that I'm sure every single one of you uses, but most of you probably have never given much thought to and that is Hex. So just a quick introduction. I'm Todd Residek. I'm a senior software engineer at Weedmaps and you can find me most places online at Super Simple or some derivative thereof. So just a little introduction. So what is Hex? Simply, it's the package manager for the Erlang ecosystem. So you can think of it like what NPM is to Node or crates is for Rust or what RubyGems is for the Ruby world. And it was brought to us by this guy, Eric Meadows Johnson, in December of 2013. So how does it compare to some of those other systems? So one metric is number of packages available. So you can see Hex has about 5,700 packages at last count. Compare that to Ruby, right around 9,000 crates a little over 13,000 and NPM. I know that looks like an error, but that's actually right, 500,000. So I'll let you figure out where that huge number comes from, but maybe suffice it to say quantity doesn't necessarily mean quality. And some context as far as how fast these numbers are changing. So when Hex hit the 5,000 mark, RubyGems was at 8,800. So just in a pretty short time, you've seen, you know, 700 Hex packages added compared to only 200 RubyGems added. So why do you want to become a Hex power user? So a couple of reasons. It may help you work faster. So rather than to fumble around with your dependencies or find out how to, you know, do something in Hex, you'll be able to work faster. You could possibly prevent some issues from coming up in the future. And it's going to help you debug, you know, problems with your dependencies or with anything that involves Hex really on your system. So real quick, the anatomy of a Hex package. Hex packages look like most other mix. All right. Let's start over. Look like just about any other mixed project with a couple of exceptions. So let me, all right. So here's an example of one package and most of this should look pretty familiar. The only thing I would say to notice in here is this license markdown file that's at the top. And that's optional. You don't have to release Hex packages with the license on it. But if you do, then that file is required. And the contents of that file are the complete text of whatever license you've released it under. And let's take a look at a mix file. So this is a common mix file for a Hex package. So again, this looks a lot like other mixed files, but a couple of things to point out, the version. So Hex requires you to release packages in semantic versioning. So hopefully you're doing that already. But just to let you know it is required, or expected at least, the description. So this is a brief two or three sentence description of what this package is for and what this package does. It's important because when people go on Hex PM to search for a package, this is one of the two fields that that search looks at. So you want it to be useful and really do a good job of concisely describing what that Hex package does. And let's see, the depths. So this is not Hex specific, but I wanted to point out this depth just for one reason that is sort of Hex related. And that is that you can add dependencies from Hex PM and that's kind of the default. But you can also add dependencies directly from a GitHub location or even from a local path. So just by using the path keyword in the dependencies, you can load that from a file that's on your computer system. So the reasoning, why would that be useful? Let's say if you're developing a package and you're not ready to release it yet, but you want to test it out, you can do it there. Or maybe it's a package that you think only would be useful to you. So you don't want to clog up the ecosystem with something useless or maybe it contains proprietary information. So you can still use the Hex system for that library without having to give it to the world to see. So the, let's see, the other two things. So in this package list, this is Hex specific. The name, that's the name that everyone's going to see. And that's the name that they're going to add to their depths of their mix file. So that has to be unique and organization. So organization is a relatively new feature. And I'll get to that a little bit more later. So you may or may not see that, but if you do put an organization in there, just that, that means that this package is going to be published to a private repo and not to the Hex public repo. All right, package naming. So there's really only one hard and fast rule for naming a Hex package. And I'll read it verbatim because I think it's important enough to do that. Avoid using offensive or harassing package names, nicknames or other identifiers that might detract from a friendly, safe and welcoming environment for all. And I think as some of the other speakers and Desmond pointed out, you know, part of what makes this community great is the people that are in it and the respect that we show for one another. And you know, if you're, if your programming language turns into 4chan, it's probably not going to last that long. So just basically be cool or 8chan. That would be really bad. Thanks for laughing everybody. All right. So there's only one hard and fast rule, but there are conventions. And you know, sometimes as a, as a newer language and a newer community, you know, it takes a while for these conventions to take hold and maybe they're not documented. I think we're at the point in the Rails community where those conventions are pretty well set and documented. And, and I think in some places, at least in Elixir, these aren't as obvious. So the naming conventions. So first one is if you're adding functionality on top of another package, use that package's name in your package name. So an example would be if you're adding an authorization library to, on top of plug, you would want to name it plug underscore off, rather than to call it, you know, just off or, you know, something other abstract. That's going to help people, you know, understand how it's going to fit in with other dependencies. Avoid namespace, space conflicts with existing packages. So this has more to do with the modules inside of your application. But in that same example, rather than to call your module plug dot off, you, because that's, you know, intervening inside, into the plug namespace, you want to call it, you know, plug off, for instance, so that you have a new fresh namespace that your package owns. So when porting a library from another ecosystem, traditionally, you're going to want to add ex to the name. And so, you know, for instance, if you're, if you have a Ruby gem that you like, let's say faker, for instance, the elixir version of faker is called ex underscore faker, or might be faker underscore ex. So that's common. So if you're just doing a direct one to one port from another package, or from another ecosystem, rather, either prepend it with ex, or append it with ex. So names, names are first come first serve. So that means that even if you're the trademark holder, you may not have the ownership of that hex package's name. So for instance, if you are, you want to make a package that acts as an API wrapper for Spotify, and no one else has done that yet, you are totally able to just call your package Spotify. Now keep in mind, name squatting isn't allowed. So, you know, I know I do this, and I'm sure a lot of other people do this too, is you get this great idea and you say, man, I'm going to, nobody has built this Spotify elixir library yet. So I'm going to do that tomorrow, next weekend, you know, and then now it's four months later and you still haven't done anything with it. So you can't name squat, meaning that you can't just publish a trivial package that doesn't actually do anything just to sort of stake your claim on the name. If you publish a trivial package, you should expect that it's going to get removed. All right, now to the good stuff. I'm about to do the two bravest slash dumbest things any speaker can do, and that's number one, live coding and number two, rely on the internet. I know, wish me luck. So let's see how it goes. So what commands should you know? So number one, let's get out of here. Anybody know how to quit Vim? All right, mix hex dot info. This is an internet related, so that's fine. So this just tells you about your local hex install. So what version do I have? What was it built with? So why do I want to know this, Todd? Well, I'd say one reason is, let's say you're having some weird problem and your coworker is like, hey man, I'm not having that problem. Works fine on my machine. Maybe the first thing to do is, both of you take a look at your hex info, see if maybe you have different versions or they were built with different versions of Elixir or Erlang. So now add a package name to that, and you'll get information on the releases of that package. So can everybody see that all right? Yeah. Pretty good. Okay. So here I go, hex info, Postgrex tells me what it is. It's the description, Postgrex driver for Elixir. It'll give you the last eight versions and you'll see an ellipsis if there's more than eight versions of the package. In this case, the two most recent versions, the 1.0 releases or release candidates, those have been retired. And I'll talk a little bit more about what that means later on. And then let's see, we've got the maintainers. One of these guys is here today. All right. I'll let you figure out which one. Oh, and the config line. So this is a pull request waiting to go out, but generally the config line is going to tell you what version you should, or basically just copy and paste that into your depths. In this case, there was a known bug with this. So this is telling you to put this release candidate in there, which it shouldn't. And so the next release of hex will fix that. So in this case, it would show 0.13.5. That's the one that is recommended that you use. Let's see. And going even further down the well of mix hex info is when you add a version number or release to the package, it's going to give you release specific information. So this is Honey Badger. And what's useful here is that it's going to show you all the dependencies that this package has. And so you could use this if you have hex packages that share dependencies. This might be a good way to figure out exactly what those requirements are. And try to resolve some conflicts there. So I'm going to move fast here. And if anybody has any questions, I'd love to meet new people, so come find me after the talk. So the next command to know is mix hex search. So it's pretty self-explanatory. This goes out to hex docs API, or I'm sorry, it goes out to the hex PM API and searches for, searches for hex packages that match that name. So here hex search alpha. And so this searches across the description fields and the package names for anything that matches alpha. And it's going to give you up to 100 results, but usually it's right around 10 that you'll see. So these are all the hex packages that match on that search. So if you want to search on multiple terms, so let's say alpha plus beta, so it'll search both of those words. But just keep in mind that this search right now is an inclusive search, not an exclusive search. So it's just a real basic postgres, I like search across those columns. So you're going to get any packages that match alpha or beta, not necessarily both. And so there's talk in our project to move this into a more advanced search technology, so something where you could do more of the advanced searches for that, but as of yet it's still not available. So and one more on mix hex search, search and add an organization flag. Just shout it out if anybody here has a private organization on hex right now. What's that? Nobody? Okay. Oh, all right, hand up. Okay, so so adding the organization flag will search your private repo rather than the hex PM repo, which is the public repo. So in this case, super simple as my private organization, and so it's giving me search results from that. Let's do this next one is my favorite. So mix hex docs. So, you know, now that you found some great packages, I assume you're going to want to read the documentation. So you can do that right from the command line right with with the hex that you have installed. So let's see x unit. So mix docs, hex docs, open x unit. We'll go to the hex docs PM website and open up the x unit documentation right there. So and it said that opens up in a browser. It's automatically going to give you the results for the latest version of that package with some exceptions. So searches for e x elixir x unit ix logger mix are going to give you the documentation version that corresponds to your the elixir version that you have currently installed. So if you're running on, you know, one four and you search for elixir here, it's automatically going to bring up the docs for one for release. And so here's a good one. So mix hex docs fetch and let's do plug. So fetch goes out to the hex docs site and downloads all those documents for you onto your local machine. So let's say you're you want to read about, you know, some some library on your flight home and you don't have internet access on there or you have a commute to work that doesn't allow you to have internet access. This will allow you to download, download those to your local machine. So let me show you where those are. So your hex home folder by default is just in your home dot hex. So in the docs directory there, you'll see all the packages that I have downloaded. So if if you go into those, then they're broken up into subdirectories mix hex open plug offline. Sorry. Mix hex docs open plug offline. All right. So this, you probably can't see it, but instead of serving that up from the hex docs website, that's a local file. So again, like if you want to grab documentation that you know you read a lot or you're you want to read and you know that you're not going to have internet access, then you can fetch those. It's automatically, it's going to go out or sorry, when you hit that fetch offline flag, it's going to search your local directory first and see if you have it. And if not, it's going to go out the hex docs and try to grab it for you. So obviously you need to be online once when you download it. But after that, it can open those offline. Sorry, there's a lot of great stuff about hex and I try to whittle it down into 20 minutes. But I have a link at the end that that's going to share a lot more of these tips and tricks. So mix hex config. So this shows your local hex configuration. So this isn't a file again in your hex home and the hex.config is the name of the file. So in this case, I have three config set up my username, which everybody should have HTTP concurrency and foo. So yeah, that was so mix hex config foo.delete. All right. So get rid of that. So there's only there's only eight configs that hex actually will look at and most of those are specifically used if you're going to run your own hex server. So these are the ones. So API URL offline. So like I said, unless you're running your own hex server, you're probably not going to mess with these too much. The one exception I'd say is the HTTP concurrency. And what that does is tells hex how many packages basically to go out and try to get for you at a time. So the default is set to eight and that seems to work well. But if you have a lot of dependencies, let's say in and your build is taking long, you can increase that number. Or if you find that you get a lot of sort of race condition errors, you can decrease that number. So just keep in mind if you play with it, to some extent, you're going to be running at your own peril to increase it too high because it's still the dependency tree still has to figure out, do all those calculations. So if you're getting all of them at the same time, you know, you could run into potential problems. Okay, one last one. Mix hex. All right. So mix hex outdated. Awesome auditing tool. So you can do this on your project and probably should do it every once in a while. So in this case shows all my dependencies, shows if I have the latest version or not, and if an update is possible. So in this case, I have alphabetify 010 is what I currently have installed. The latest is 103, but an update isn't possible. So that means that in this case, it's a major version change. So there's going to be a breaking change. It's not recommended that I update or have another dependency that depends on the lower version. So it won't let me update that. But x docs, for instance, says yes. So it'd be very easy and probably recommended that you update it at that time. One thing about that is it's not going to recommend pre releases. Okay, it's not going to recommend pre releases. So it's only going to give you stable versions unless your package that has that dependency is also a pre release. Mix hex audit. It's going to show you retired packages. Again, that's that's a sign that something that you're depending on is deprecated and it's probably time to look at changing it, updating it. So yeah, I just a quick shout out to the people that pay me to be here. Weed maps. Thanks to MPACs for hosting this and all the organizers and the hex and come find me if you have any more questions after this. Thanks. Thanks a lot, Todd.