On 05/08/2014 02:02 PM, Paul Moore wrote:
Socially, this change does not seem to be having the effect of persuading more package developers to host on PyPI. The stick doesn't appear to have worked, maybe we should be trying to find a carrot? Or maybe we have to accept that some developers have sound reasons for not hosting on PyPI and work with them to find an acceptable compromise? Has anyone checked what Stefan's reasons are for not hosting cdecimal on PyPI? Do they represent a use case that the PEP hasn't considered?
Well, I do host a small handful of modules on PyPI, but I can say that some of my pain points are: - getting a good name: the obvious ones are taken, so the search begins to find a name that is not taken and yet still feels at least somewhat appropriate: my OO path module ended up being called strpath (dumb name); eventually changed to antipathy my script param line parser is called scription (okay name) my enum backport is called enum34 (blah) my dbf package is called dbf (lucky lucky lucky!) - reputation of PyPI is not that great: anybody can upload packages, no curating is done, once there the name is taken for all time, no standard version numbering, . . . (granted, these are my impressions and may not be entirely valid) Anyway, I know it's a volunteer effort I don't want to criticize those actually running it, but these are some of the problems that I see with the service itself. -- ~Ethan~