On 19 September 2014 13:15, Akira Li firstname.lastname@example.org wrote:
Paul Moore email@example.com writes:
- C extensions aren't a huge problem to me on Windows, although I'm
looking forward to the day when everyone distributes wheels (wheel convert is good enough for now though). 
I have the opposite impression. http://pythonforengineers.com/stop-struggling-with-python-on-windows/
Well yes, but that article is clearly focused on scientific use (a known "worst case" area) and ends up recommending conda (which is a perfectly fair solution, and as the author states, works well).
My comment was a bit unfair, though. I have a C compiler installed (which, although it's not hard to set up VS Express, isn't normal). And I also treat "find a wininst installer or egg and run wheel convert on it" as trivial and acceptable, which it isn't for people who aren't packaging specialists.
But we're working on this, and I stand by the statement that when projects routinely distribute wheels if they include C extensions, binary dependencies will be a minor issue.
PS I should also note that even in its current state, PyPI is streets ahead of the 3rd party module story I've experienced for any other language - C/C++, Lua, Powershell, and Java are all far worse. Perl/CPAN may be as good or better, it's so long since I used Perl that I don't really know these days.
The discussion here is about packaging, not about finding 3rd party packages to solve a problem. I know of no better way to find a package to parse an ini file in Java than google, which is no better than Python. And what I found was packages on sourceforge and other generic hosting sites.
Maven may be a central repository - I've never used it myself as the complexity has always scared me off (you could say that about most of Java, though ;-))
Or: "The artifact approach is unambiguously better for any production deployment. The source-based approach found in Ruby, Perl, and Python is a problem for me more often than a solution." https://news.ycombinator.com/item?id=7070464
Again, that's deployment rather than discovery.