 about three or four years ago, around the time of my first Ruby conference, second Ruby conference, I had the idea of let's take every single gem that's in Ruby on Rubyforge and mirror it, open them up, extract all the metadata, and then do a talk about it. Luckily enough, that talk didn't happen. But it's about four years later, and there's a lot more gems, and I figured, why not do that? Unfortunately, I gave this talk the complete wrong name, because this is the anthropology, that is the study of humankind, not the study of gems. So, we have gemology, much better term. And what we're going to do is take a tour of the metadata and all the information that we have that's in RubyGems, and see what we can find, if we can find out anything interesting, and if we can actually learn anything from it. So, I have a project called gemology, it's on GitHub now, put it up in last night, and it basically boils down to a RubyGems mirror. So, how many people have ever downloaded every single gem on Rubyforge? Alright, I know both of you, three. Oh, I haven't read yet. So, it's actually not too hard. There's this great new RubyGems mirror gem called RubyGems mirror. And basically, you can just download every single gem. The gem files themselves is about, I think it was about 40 gigs, if there's still this gem files. If you extract them further, I forgot someone posted how big that was, but I haven't extracted them all into one big directory now at once. So, you combine a mirror of RubyGems with a webbook. Does anyone use gem webbook? Alright, we have two people. How many people actually know it exists? A few more. Okay, go to your man page. You should do gem webbook dash dash help. So, part of gemcutter has the ability for you to subscribe to any gem publishing. Subscribe to a particular gem, or you can subscribe to all of them, and that's what this does. So, we have gem webbook, which subscribes to every single gem push that happens. Every single time a gem gets pushed to gemcutter, all the webbooks get called as appropriate. And I have one that sits behind Sinatra. It takes that webbook, throws a job on rescue. How many people use rescue? Yes, isn't that a great piece of work? It fetches the gem from gemcutter, which actually gives up being from cloud front, grabs it, downloads it to my slice, and then I have it on Rackspace, so it's in cloud files, stores it in cloud files, and then that kicks off another job, which extracts the metadata from the gem. So, how many people work at Eric's Doc this morning? Double Eric, of course. So, for those of you who don't know, a .gem file is really just a tar file, and it has two files in it, metadata.gz and data.tar.gz. So, the metadata.gz is a YAML file, and the data is just a list of all the files that are in the gem. So, it's a pretty simple and nice format. So, that metadata, that's in that YAML file, kind of people have actually looked at a RubyGem specification, like the full thing. Alright, so we've got a few more. There's a lot of stuff in there that most people probably don't realize. There's a lot of stuff in there. So, how many people use Rubyforge Project in their gem? Yeah, there's a few, yeah. There's a couple other interesting ones in here that not everyone knows. There's actually a license field in the RubyGem spec. No one uses it, or maybe two or three. Huh? No, we should be using it. No, I'm saying these are things that we should be using. There's some interesting stuff in here that would be helpful to use. Oh, of course. Then it makes it really easy. So, and then the other, another big one that people don't, some people do, not a lot. How many people know you can cryptographically sign your gems? Yeah, see, the same dozen people are using their YAML stuff. So yes, if you are worried about the security, or just the author of the knowing that a gem was signed by the author, yes, you can sign your gem. It's in there. But just why don't you look at the man for gem? I think it's called gem cert, and then you can look at it. It's best to use a felt tip kind of sign. Yeah, yeah, you can, felt tip works out really well, yeah. But there's all this data in here, and I really wanted to look at it and say, well, what can we find out from all of this data that's available for all of these gems? I mean, you know, the first one I thought of was, well, actually, one that's really important here is release date. Every time when you type gem build, if you don't send it in your spec, please don't, then the release date, the current date on your computer is stored in your gem. So the date you typed gem build is stored in the gem file itself. So let's start out with that piece of data and ask the question, how often do we, as developers, release gems? So you've been raising your hands. Let's do it again. How many of you have a published a gem? Okay, keep them up. We're not done yet. We're going to find out how old you guys are. So who has only published a gem to gem cutter? Oh, wait, wait, sorry. I'm doing it in the wrong order. Drop your hands if you've only published a gem to gem cutter. Okay, who's published a gem since 2008? Seven. Six. Five. Oh, we still have four. Three. Okay, there we go. So you can't get any earlier than 2004. It's pretty much the rule. Although some people apparently have set their gems to have earlier dates. So that's one of the reasons. Yes, yes, there is a gem out there that says that its root was released in 2000. And now you've told us how to do it. Yeah, and now I want to tell you to never do it. It's just a wrong way to do it. So we're going to start with the metadata of a release date. So we're going to start out with something earlier. So gem, Chad, Rich, David, and Paul put together Ruby gems in 2000, or that was when 2003 was when it was born. The first Ruby gem server went live in I think approximately late 2004. So this is a graph of every gem that was released by day in 2000, through the end of 2005. Sorry, apologies. This is a little at the bottom. But basically at the bottom we've got months. On the side we've got gems released per day. Look out there. Between 2004 and 2005 there were 1,589 gems released. And repeat over there about 20 gems released in one day. That's a fair bit. It's not too bad. It looks like late February, maybe April, March 2005, we had 20 gems released in one day. How many of them were Easter eggs? I have no idea if any of them were Easter eggs or not. But that's at the end of 2005. Let's go to 2008. So we extend this graph and go into 2008. And we see it's been taken off. It's doing pretty good. 2005 and 2008. Now we're approaching, this is now by month. Sorry, doing it by day doesn't work well in these graphs anymore. So we get up here. At the end of 2007 we're doing 500 gem publishing, 500 gems published a month. Which is not too bad. So between 2006 and 2007 we have 7,949 gems. As opposed to the 1,500 from the previous two years. So we continue on. So now 2008. We add 2008 to the mix and it's just skyrocketing. It's a nice curve here. We're doing really good. 2008 on itself had 9,000 gems. So every single year we're getting more and more. Every single year. So who knows what happened at the end of 2009? Anyone? Github? No, gem cutter goes live. Late November. Are these stats for Rubyforge or for Rubyforge plus Github? There's no Github date in here. This isn't actually downloads. This is publishing. Right. So yeah, this is the release date values. So this is missing all in any gems that people were just publishing on Github? Any gems that were only published on Github. Yes, that is true. So Github said they had as many as Rubyforge. But here's the really fun part. Late November, last year, I think about the 16th, gem cutter goes live. I think it had an impact, don't you think? Right here. This is gem cutter. That's the day it goes live. I mean, January to October of 2008, we have 13,334 gems published. That's January to October. So those are the Github gems? These are still just gems that are available. I don't know where they're published. They may not even move to Github. So I suspect that's a lot of that stuff. Because I can't imagine that everybody's waiting to write gems. No, probably not. But this is their release date. So this means the gems were repackaged. Right. So yes. But this is just the end of last year. Now we go to November and December of last year. We have 7,649 gems produced, which is more than half those produced in the previous 10 months. Which is kind of cool. But you think this might be ever in behavior if that was just gem cutter, or just all the important Github. It's not. This is through last night. Yeah, gem cutter. Since gem cutter has gone live, we have published 50,000 gems. That's individual releases. Any of your gem that has 15 releases in the past year, that's 15 individual gems. So give yourselves a round of applause. In other words, in the five years before gem cutter, we had 34,000 gems published. In the previous year, we've had 52,000 gems published. I think this is pretty cool. And it shows that the ease of publishing a gem is actually, there's a high correlation between gem cutter and the ease of publishing and more gems being produced. What if we take out RVM? If I take out RVM? RVM's not a gem. So this means we're publishing 150 to 200 gems a day, right now. Yes, Steve? Yeah, the highest point in up to 2005 was 20 a day. The highest now is over 200 a day, but we're never dropping below like 100 to 120. Why don't we count the next gems? Then we're down to like four. Now the fun part is if you take this and you're like, okay, so this is cool. We've got all these new gems. Does this same trend across batteries? This is first releases of a gem. So the first time a gem shows up, this is the same trend graph from the exact same period of time. You still get the gem cutter. New gem releases have also skyrocketed, which is kind of cool. First release of new gems. That shows the get-up on. Yeah, that first spike is probably the get-up on. Yeah, that very, very first one. But, I mean, even go down here, it's, hey, right now we're not too far below it. At 900 and some odd per month, you know, that's last month. We haven't even finished. We haven't even finished November, and it's, well, the slope is a little off. So we're right now having finished November over 6, 800 or something like that. Now here's the fun part. You take just the new releases of gems, but when we do these with first releases of gems, we can also figure out first time gem authors. So these are people that have never published code before. You know, or maybe they have, but they haven't done it as a Ruby gem. So first time gem authors, of course, we've got our get-up spike here. Man, that's a great point. I was trying to figure that out, but that is the get-up spike where it imported all the stuff. But we still have, these are first time authors. So I have to say this is kind of cool. We are encouraging mostly open source, all these are all probably open source license of some type, but we're encouraging open source publishing of gems at, you know, hundreds a month. First time publishing. I think that's actually pretty cool. This is an encouraging of people producing and showing their work to the world. I think that's pretty cool. Now the fun part is when people are doing all this work and figuring out, you know, they're going to release something, when do they do it? I mean, well, we see that they do it all the time here. But what day of the month do they do it on? I mean, this is kind of just a joke graph. It's kind of fun, but you look at it and you go, hang on, it looks like on the 6th of the month. So whatever people are doing around the 6th, 7th, 8th, 5th, that's when people push gems to jump cut. I don't know why, who knows. This one I don't really like as much as the next one. Tuesday? I mean, what's up with Tuesday? Why do people publish gems on Tuesday? Do you have an answer? Okay, so... Do we release them on Tuesday? So what does the gather and most gems get released on the first Tuesday of the month? Yes, exactly, yes. So you put these two together and we get that most gems are released on the first Tuesday of the month. Yeah, it could also be... Oh, there we go. But it does show, hey, we as programmers, we actually do sort of cut down on the weekends. Not much, but we do cut down on the weekends. Yeah, that's just the release though. This is how we release. How many of those people are working over the weekend? Yeah, yeah, yeah, yeah. Everybody's working through the weekend and we'll publish on Tuesday. Yes, there you go. Yeah, so this is kind of an interesting name. I mean, I just kind of find this fun. This actually is the anthropology. Yeah, this is the anthropology of ruby gems. When do we put it? Yeah, so there we go. But the next part is, this is kind of all fun. It's, okay, when are we releasing, when are we releasing, how often are we releasing? And I think this is just awesome stuff. But let's switch to a different piece of metadata. What ruby gem version are we as developers using? So one of the pieces of metadata that it shows up is the package ruby gem version, published in the gem. And I forget, Eric, when did that go in? Okay, so around the zero nine ruby gems time frame is when the version of ruby gems was packaged into the gem. So we look at that, kind of break this down. On the left hand side, we've got a ruby gems version. And on the bottom, we've got the count of the number of gems that have that value. So we can see, you know, well, zero nine is, somebody was doing it in zero eight eleven. That's kind of interesting. Zero nine. But it looks like most people are using one three five, one three six, one three seven. But if you take this back to the previous slide, which is when are all the gems been released? It's been in the past year. One three five was February 2009, something like that? I forget, Eric. I don't know, but I looked it up. And these one three five, one three six, seven is about the last year and a half of gem release itself. So this correlates highly with the actual just general exuberance in publishing gems in the past year. But it's kind of cool. I don't know what exact dates on these are, but we can see that these are the versions. Somebody's publishing gems with one seven three one. That's you? That might be you. Okay, all right. So another question we might ask, how many, we've got free releases. How many people are publishing pre-release gems? I've done a couple. Yeah? Yeah. So with pre-releases, we have metadata of the pre-release. So if you look at the source code, basically the rule for a pre-release is if the version has a letter in it, it's a pre-release. That's how it's determined whether it's a pre-release. Yeah, there we are. Letter has a pre-release. So if we look at just the pre-releases and say, hey, our pre-release is taking off. Well, yeah, it looks like it. So people are doing it. I mean, this is Relief Month, so it looks like in October we had, you know, maybe 300 pre-release gems pushed. Now, another thing I didn't look, I looked into a little bit, but it's not in this talk, is how many people have dependencies on pre-release gems? Yeah, no, they exist. They exist. Believe me, they exist. Not sure, I feel about that. Oh, that's another, that's actually really good to look at. How many gems that are not pre-released themselves depend on pre-release versions? So I'll add that into the list of things to experiment with and look at. Thank you for the answer. So we have pre-releases, people are using them. How many people find them useful? Use them? All right, awesome. So we have extensions. Are extensions trending up or down? Are people doing more extensions, or are they doing less extensions? I see extensions. This is extensions. You can actually have Java extensions and C extensions and stuff like that. The way you determine extension is in the metadata, is basically there's an extensions field that you put a file in, and when the extensions run, it runs that file. So, in this case, it's CXTconf.rb. Or, I forget, there's two other ways even though the instance is just a rake file or a rake file, both of those can be in there and it'll just run. So, here are extensions. Actually, extensions have taken quite the skyrocket here in the past month, so that's kind of interesting. So extensions, not exactly the same explosive growth as we have with regular gems, but we do have quite the number of gems with extensions. Now, this is a little, there's another question we need to have as a follow on here. So extensions trend, and there's 4,460 gems in Ruby VMs that have extensions. Now, the interesting part is, so extension, if your gem has an extension in it, it really can only be run on Linux or Mac, or something, or that's got the build features because it's probably C code. It might be Java, you never know. There's one that requires Python. There's one that requires Python? Which one is that, James? Interesting. There's one gem that uses Python to build the V engine, and it requires Python in the extension. Hey, there we go. But the interesting thing is, if we've got 4,460 gems that have extensions in them, shouldn't we probably also have approximately the same number that are non-Ruby platform? So, we'll go into this. What platforms are gems being created for? Keep that other thought in your mind. So in metadata, there's platform. It's pretty much just there. You have to set it, and there's some crazy stuff in that platform value. So, as you can see, Ruby is the dominant platform in Ruby gems. Not really all that surprising, but that's not informative because that's just, it blows out everything else in the water. We've got what? 80,000 gems that have Ruby, and everything else is less than a pixel wide. So we're going to throw out the Ruby data and see what we come up with. Here is that the dominating gem platform outside of Ruby is x86 MS-132. So we have a growing one down here of Java. Yes. This is unique gem. So a different version of the same gem would be in here is twice. Yeah, this does not include just the most recent or anything like that. If it includes, it's actually harder to calculate on that. I'm working on the best way to do that. Every gem in existence. Except for the Ruby ones in this graph. So we can see that x86 MS-132 is, by far, the dominant platform outside of Ruby. Java coming in at plus second and x86 mean w32 third place. Which is kind of cool. That's some interesting stuff in here. We've got x86 Solaris one up here. Not sure where that one came from. If you are building gems, you should find some of the mean ones. Yeah, yeah. If you are building gems that have a native component, then you should be focusing on the x86 MS-132 one there. So Dr. Nick was talking about that and he's promoting that. So if anyone wants to make gems on Windows, you know you can talk to Dr. Nick. Take care. That was helpful for all of you. Hey, you open your mouth? I've said it to people your life. Some got lost in Australia. Now there's some interesting stuff in here. We've got some really small ones. We've got RPC Darwin, Spark Solaris. I mean universal.net. There's a gem out there that has as a platform a universal.net. So someone's making gems that will run on the CLS. And then of course we've just got MIPS, Allegro, Excel and the known. Those must be pretty old. But here's the thing. We've got 2333 total gems that have a native platform. And we've got 4,460 gems that have extensions. So take note of this people. We need to make sure that these numbers are starting to get closer and closer together. So are people making note of Ruby language capability? Incapability. This basically means are people taking note of the differences between Ruby 192, 191.8, you know, going on down. Because one of the fields that you can set is the required Ruby gems version and the required Ruby version. So if someone is publishing a gem, I've encountered this several times where the gem makes use of some language feature, like TAP, that's the one that I encountered. A gem included TAP in their code. I tried to run it all on 8.6. Didn't work, blew up. But there was no required Ruby version in the gem. So how was I to know that the reason this wasn't working is because the required Ruby version was not set. So if we look at this, these are the gems that count. But a lot of the old gems, this wasn't actually put in recently. Do you remember what was there on this one? So there's a lot of craft data in this piece. So we have zero and zero dot zero dot zero are the junk data in here. So we're going to throw it out. And it looks like people are using it. So we do have, the number one that people are using is setting the required Ruby gems version to 186. There are also other techniques. My gem is where, in a few places where I do have Ruby language, I just do it by having the code there. So if you aren't doing this easier, you can detect the Ruby version itself in your code and then make allowances to that one. But if you don't want to do that, there's just too many of them where it's all over the place. This is the one thing you can do. But people have been doing it since 186.7, 168. 186 is the big one. I do like the fact that we have gems being released that are saying that they need to be 191 or 192 or greater. So those I consider the considerate folks who are saying, hey, I'm using the newer language features. Don't install this gem if you're using Ruby 186. Which is kind of cool. I think those are considered. Now we're going to look at, this is the required Ruby gems version. So if you have code that requires a specific level of Ruby gems itself in order to function, this is what we see. And I forget if this is actually set specifically or if you have to set it yourself. And most of this, if you're using a development dependency, it does install the, set this directly to 136, correct? One, two, I think. One, two, okay. So that's the big one, two. Because these are all gems that are using development dependencies because that was a feature added. If you set in your specification a development dependency, it will automatically say your Ruby gems required version to at least one, two. So we can see that people are using, you know, the nice version, the bigger versions. But that's just kind of some of the interesting data that's just available in every gem. What we really want to see is whose gem is more important than somebody else's, right? So we're looking at dependencies. But I have to digress and go on a small rant. Who knows what this is? You also know it is this. Yes, yes. Twiddle walk is the appropriate term. It's a twiddle followed by a walkup. Okay. Look at that. That's the term for that. No, no, twiddle walkup. This is a twiddle walkup. Now, this is a very important thing that you should all be using. Because if you have a gem and I say I depend on riddle greater than or equal to 1.3, that means you can use it if wibble3.0 comes out and it will install wibble3.0. Wrong. Wrong. What we want is twiddle walkup 1.2.3 or something like that. Which means I can use any 1.2 system and it will not install 1.3. So people, read these. Understand why. Take note, I'll give you a moment. You can, you know, shoot a photo of this page and read these two websites. It's really good. You know, appropriate versioning is critical and we're getting 50,000 gems in one year and the bridges are screwed up. You know, that's something to worry about. And to show you kind of how bad it is. Okay, so you can't see the bottom here but that really tall one. Wrong. This is greater than or equal to on runtime dependencies. I could. And I might. Now, one of the things that I'll get to this in a minute one of the things I want to do as a follow-on to this is, well, I'll get to it in a moment and talk about this. That's wrong. And these guys are nice. Yes, they're going to be happy. Read, we have development dependencies. We've got development dependencies that you use greater than or equal to. Okay, yeah, that's not really going to work. But the development or runtime they're using twiddle walkup are your friends. These are people that are considerate and understanding of the APIs that they depend on making sure that they're compatible with those upstream APIs. Some of you, we should all be understanding and figure out. So that's my dependency grant. Now I'll go to the runtime dependency graph. So this is what it looks like. Yeah, there's not much you can see there. This is every gem. Just the gem, not individual versions. This is the dependency graph between every single gem in RubyGems. The blue one is the one that's got the highest number that it depends on. It depends on? People that depend on it, yes. And my next few arrows are going to be in the wrong order. So that's not a no-goo-geary. That one's a no-goo-geary. It's actually active support. It's the number one gem that has a direct dependency. No-goo-geary is up there too and so is hell. So there's a couple others and there's like Abacus, A2WS. But the interesting one is actually I didn't think it was going to be active support. So that was a surprise to me. What did you think it was going to be? I didn't know, but I didn't think it was going to be active support. I was actually thinking it was going to be rake or something along those lines. But I haven't traversed these graphs backwards. I mean, who does active support depend on? So should that weight be transferred down to whoever active support depends on? So I haven't done any of that type of graph analysis, but I will. People don't risk rakes. They assume to. Nick says that they don't include rake because it's assumed. The other difference is that most people don't spot a rake jam to get the rake. Right. Yeah, most people don't stop raking. So the other one is that was a runtime dependency graph. And to draw it, the tool I was using is called Toolip. I was just playing with it. And the only way you can draw it is in three dimensions. So the other one is the development dependency graph. That's what this looks like. This is if you just include the developments. My GenDefense has a development dependency of this other gen. Yeah, it's so messed up. But the way this draws it is all those gems in a circle, they all depend on the one in the middle. So you can see that one with the red in it. Any takers on what that is? Say again? Oh, no. Juller? No. We'll get to it in a minute. RubyGems looks really highly connected, but they're not. This is how dependencies work. So what we have down here on the left-hand side is the number of gems Let's see. Let me try this. We have one gem down here that 150 other gems depend on. There's one. And this is runtime, so we know it's active support. But over here on the other end, we've got over 1,500 gems that are dependent on by someone else. By one other thing. So this is a nice long tail. But this also means these are 1,500 gems right here that are published that also need to be worried about their downstream folks. And then it's just a pretty much a perfect long tail that shows up right down there. Yeah, active support. So we do the same thing but with development. And we see we've got there's one or two gems down here that 120-some on other gems depend on. And we have a whole bunch over here 400 plus that have one person that depends on them. Those are probably components of some of these other gems. Yeah, so these could all be components. I mean there's 400 of them. I didn't go into the analysis of what they all were. But these are 400 gems that someone has said that this is a development dependency. Which is kind of cool. I think that's really cool. There's a huge slew. There's a large number of gems in here that people depend on for development purposes. This is the inverse. How many gems so if I have a gem, and I publish it how many gems do I depend on? So right here we've got well, let's do it this way. I've got one gem that has 40 dependencies. Now when I tell you what it is you're going to go, well of course it's the Rails Toolkit. Which basically says install this gem and you'll install everything that we need for Rails. That went way up with Rails 3. Yeah, I know. So this is just one dependency. You're not actually walking the graph. Yeah, I'm not walking the graph. This is just direct one degree dependencies. But what we have over here interesting is that first bar is zero. There are over 25,000 gems in Ruby gems that have zero dependencies. Actually that's cool. They declare zero dependencies. Correct. They declare zero dependencies. So that's very true. But we do have 20,000 that declare one. Which means that that's an explicit declaration of a dependency. Which is pretty cool. That means hey, I'm making an effort to say I am depending on someone else and here's who it is. So we've got 25,000 different zero dependencies. So, what did we learn during the talk today? What did you guys learn? Anything interesting? Yes. Yes, a lot of people are not using TwiddleWalka to require active support. That might be one. That's a good one. Any other good ones that someone got? We know what TwiddleWalka is. We know what TwiddleWalka is. Okay, I'm asking that you got it. Alright, that works. Finally, this is what I got in this study. I didn't think so. But the gem metadata has junk in it. All over the place. Author names. Okay, people. That's supposed to be an array. People are putting in like a CSV string. So you get author name comma, author name comma, and it just shows up. So it's kind of hard to figure out the author's names. Encoding issues. The YAML file that's in here is supposed to be UTF-8. Not all of the YAML files are UTF-8. I had to play some funky encoding tricks and try to use some stuff to actually read some of these because of the encoding. Somebody encoded their file as EmacsMule, which actually isn't even a... It's even using a code page. But there's a lot of stuff in here that's of different code pages, and depending on what version you're using, so there's very few, but the gem metadata has some encoding issues that we probably could work on. Developers lie. Nobody's published a gem that's in 2000, so that's the big one. What the value that's in the metadata that you have control of, sometimes you lie. So gem needs a win command and I'm going to start it. I think we have... Is anyone else here a Fedora contributor? Fedora Packager? Okay. I do that, and there's a great RPM link command. You've got your packaging as an RPM, and it gives you this list of warnings and things you're doing wrong and your specification, and files that are listed but are missing or that are in there but not listed, that kind of thing. So we need a link command that's going to go through and say, okay, here's the right files, all those sorts of stuff. Making the link command part of the gem build. It does complain about something, but not enough yet. Yeah, it complains about some things, but not enough yet. And sometimes it complains about too many things. All right. It lies, yes. So there's other things. Yeah, we can do different things like those, rating the gem's base and the quality of their metadata. There's a lot of stuff we can do, but a couple of the big ones, I'm sure you have a license in there. I mean, I didn't show it in here, but I tried to detect if a gem had a license in it, whether it had a license in the field or had a file that looked something like a license in the gem itself. I think we have 5 to 10,000 gems with no license in them. About the readme. I mean, I didn't check inside the readme. I was looking, that's another thing. It's a really simple one right now. Yes, in the readme. So making sure that we have a license in the gem. I want to know what the license is, so they can deal with it. Yes, there is a license field in it that can be up to 64 characters long, I think, but no one uses it. So you can do that or just include a file. So I think part of this link command, I still want to figure out all the other things we can go through it, but putting a license, making sure if you list files that look like tests, you actually put them in the test files section of the spec. There's a lot of people that have their tests, but they're not in the test files. They're just listed as included in the files. There's one case in particular where I have a live by home issue. Okay, a live by home issue. That's a different dependency. I've got a gem and it requires a TZ info. Does it care whether it's the TZ info gem or active support after the interview? And as far as I told you, no way to actually put that in a jumpsuit. To depend on TZ info? You basically say, I either need TZ info or TZ info. So you need a dependency on something that provides a capability. And that would be even more... Yeah, and an RPM is something similar where you can say, I depend on web server. And so if you've got internet, that's probably going to do it. Just to make some version range of TZ info, or some version range of active support. Sure, conditional dependencies, one or the other of this set. So the man talk is back there and we'll be good. So there's a lot of stuff more to analyze. We're just talking about a bunch of different things right here. And so there's more to analyze. I want to do a more in-depth graph analysis to figure out how two levels deep, three levels deep, see, is there a runtime dependency that depends on a development dependency to figure out these different graph analysis and see what you can come up with and figure out some interesting information. So that's pretty much it. Any other new moments for questions or more comments or more discussion? Yes. I just want to point out you recall a lot of things that we were doing wrong. I think it's bogged that O would be the third most biggest dependency for runtime. Why is O a runtime dependency? I have no idea. Eric? Before development dependencies there was a runtime dependency I just want to point out that there are a few of the older gen that were actually the older version of O so to me, Yeah, old versions of gem packaged with older versions of O because O injected itself as a runtime dependency because there was no development dependency at the time. I think a lot of the graphs and analysis that we did were really interesting for the most recent version of 2 so that we could see are things different than that. I definitely want to look at just the most recent version of gems. Doing that is a little bit more complex with the data structure stuff I put together so I may be blowing away my current database and re-importing it all. The fun part is to download the import and extract all the metadata from here on the 512 megabytes I was using to do the download and the import and the extract and that kind of stuff takes about 8 hours to do everything. One more critical piece I saw in gems people don't package your package directory you know the PKG directory there's a couple of gems there's more than a couple who package their package directory and in the package directory there's a previous version of the gem that they didn't delete from the package directory and because that gem was packaged with the package directory the previous version of that gem so once you get this recursive there's a couple gems that are 100 and some odd makes and I looked at it and it's because 1.2 is packaged with the 1.1 gem and the 1.0 and the 0.9 and the 0.8 well the 1.1 is also packaged with the 0.9 and the 0.8 so Epic nature yeah that's Epic nature and you say you don't do versioning yeah don't do versioning there we go so yeah I like to think Tom and Qresh they don't give you snapshots or their appropriate databases and I didn't use any of the data yet but I will how many, did you look for any circular dependencies within gems? I didn't look for them but they exist so the graphing tool I said are you circular independent? and it said yes but yes we are not a directed asyclic graph as far as dependencies are concerned but I'm going to find it and I'll probably talk more about it so thank you for your time I guess that's all I got