Reading your post, I'm a little confused Iain. You state: If we consider only packages with at least 1 package depending on them, we find the median to be 3 dependent packages but the mean to be 10.5. This is due to the 15 or so packages with more than 30 dependent packages.
Now, I'm not the best at statistics, but isn't the median of *x* defined as *(min(x) + max(x))/2*? If that is the case, (and assuming that we don't have negative package dependency counts) I don't see how the median can be 3, but the mean be 10.5. Perhaps you meant the mode was 3? -E On Tue, Jul 22, 2014 at 9:55 AM, Iain Dunning <iaindunn...@gmail.com> wrote: > Hah, yeah, strangely relevant. > PkgEval runs nightly (around 1am US Eastern), but obviously with so many > people using Julia there is a lot of room for chaos inbetween runs. > > > On Tuesday, July 22, 2014 7:58:46 AM UTC-4, Tomas Lycken wrote: >> >> Look what my RSS reader just picked up! =) >> >> http://iaindunning.com/2014/pkg-deps.html >> >> // T >> >> On Tuesday, July 22, 2014 12:37:59 PM UTC+2, Tomas Lycken wrote: >>> >>> I still think the best way to resolve things if you should encounter >>> problems, is to notify the maintainers. Most people in this community >>> respond surprisingly fast =) >>> >>> There is some automated testing going on already, mainly thanks to [Iain >>> Dunning](https://github.com/IainNZ)'s amazing work with >>> PackageEvaluator and related tools. For example, if you click "more >>> options" on pkg.julialang.org and then "Show package ecosystem >>> statistics for Julia nightly...", you'll see some great data showing the >>> current (and past) state of the entire ecosystem. You'll notice a few dips >>> in the green curve, when changes somewhere suddenly broke a lot of stuff >>> everywhere - and you'll also see that most of it was resolved in a matter >>> of a few days. This happened because semi-automated issues were filed by >>> the system against the packages when they broke, and maintainers were quick >>> to fix whatever they needed. >>> >>> In the case of your problems - someone tagging a version without >>> specifying a correct dependency - that will also be picked up by PkgEval, >>> and the maintainer will be notified. However, since PkgEval only runs every >>> now and then, and since quite a lot of users today "live on the edge" (and >>> actively report issues when they find them) it's not uncommon that problems >>> like this are picked up by users before PkgEval notices them. It's very >>> likely that, as the ecosystem matures and stabilizes, this problem won't be >>> a problem anymore... >>> >>> // T >>> >>> On Tuesday, July 22, 2014 11:47:32 AM UTC+2, Andreas Lobinger wrote: >>>> >>>> Hello colleagues, >>>> >>>> On Monday, July 21, 2014 4:53:17 PM UTC+2, Tomas Lycken wrote: >>>>> >>>>> I think this problem must be resolved by better practices among >>>>> package maintainers: in short, the goal must be that as long as you only >>>>> use (the latest) tagged versions of any packages, everything should Just >>>>> Work (TM). That means, in short, that if a package maintainer adds >>>>> functionality that depends on some specific addition to a different >>>>> package, it is up to that package maintainer to make sure *not* to >>>>> tag a new version until the dependency package has tagged one, in which >>>>> the >>>>> new behavior is included, so the dependency can be correctly specified. >>>>> >>>>>> >>>>>> >>>> ... in an ideal world. All that we use around julia has a version >>>> number less than 1.0 so hiccups are expected (at least by me). The question >>>> was rather how i can help myself and if there is some undocumented work >>>> assumption. If i ever publish a package i'll try hard to follow your >>>> advice. >>>> >>>> This interdependency things showed up also in the great julia-graphics >>>> thread on julia-dev. Maybe some automatic testing could help? Maybe some >>>> dependency graph could be extracted out of the METADATA? >>>> >>>> Wishing a happy day, >>>> >>>> >>>
