On 27/03/2011 16:01, Fred Drake wrote:
I don't object to this, but I don't know that it tells you anything.
It is better than everything showing up as a module from the Python
standard library, which clearly doesn't tell us much.
Are you talking about the fact that the client code will be provided by
packaging.index ? If so, I guess we can think about a mechanism for 3rd
parties to define what the type of client originate the request.
I'd be surprised if many CI tools did a lot of downloading; the build
tools are typically responsible for that. I'd expect them to show up
a lot.
True.
More importantly, I'm not sure what you mean by "user downloads". If
I cause my build tool to download a package from PyPI, whether once or
a thousand times, that still seems like a user download to me.
(zc.buildout, at least, supports an effective caching strategy, so I
doubt the package download numbers would change all that much.)
I was thinking about the opposition between automated uses (build tools)
and casual uses (a deployment). But given it more thoughts, it seems to
be difficult to isolate one from the other (would appreciate any ideas
about that)
If I want to try out a package for some purpose, I'm going to add it
to the build of the project I expect it to be useful for; if it proves
insufficiently useful, I'll remove it.
My point is that if you don't include the downloads from zc.buildout,
or whatever tool someone is using, you're likely to miss them
completely, because what's *not* happening is a browser-based
download. I can't even remember the last time I've done that for
something available via PyPI; it's been many years.
That's true: browser-based downloads are a real minority of the use cases.
If we want to have a way to distinguish between "normal use", and
repeated use (which can "false" the statistics), we need the build tools
(or whatever does the download repeatedly) to declare themselves as
such, right ?
--
Alexis — http://notmyidea.org
_______________________________________________
Catalog-SIG mailing list
Catalog-SIG@python.org
http://mail.python.org/mailman/listinfo/catalog-sig
