On 18 April 2014 21:59, Nick Coghlan
What I am advocating for is that *we are currently doing it wrong*, as these are unlikely to be the best thing to install for most new Python users.
For Windows users at least, I disagree. I have directed a lot of people to the python.org Windows installers, and they have got up and running without any issues (ignoring website usability "find the right download" questions). Most of the time, they need nothing more than the interpreter and the stdlib to become productive. The downside to directing them at (say) conda is that 99.99% of the documentation on the internet is not directed at conda users. Most of the time, that's fine, because it's all generic stuff, but it's a trap waiting to happen. I can't tell people to use conda myself as I'm not a conda user, so I can't help them if they hit problems.
No, I don't think you'd benefit substantially from a curated stack - I don't think any experienced Python user would. But think through your own personal stack. Start from a Google search for "Python tutorial" and see how easily you can figure out how and where to obtain all those components.
Core python, plus a standalone copy of virtualenv (and on 3.4+ I don't even need that). Everything else is installed from PyPI as needed. Agreed that starting from a Google search won't get that at the moment, but that's what the packaging initiatives are trying to solve - get the infrastructure there so that more and more people say the same things, and so google searches become more accurate. My vision of the ideal is: 1. Install Python from python.org 2. py -m venv foo 3. foo\Scripts\activate 4. pip install <anything> (Note that item 4 relies on pervasive availability of wheels for packages like numpy, scipy, lxml, pywin32, etc) Oh, and everyone needs to switch to Windows so this works :-) More seriously, I genuinely think that this is the ideal solution for *all* Windows users who don't have the sort of specialised needs that mean a curated stack is right for them, and they know about it from word of mouth via colleagues in the same situation. I have no idea, and no opinion, on how practical it is to achieve this level of simplicity on Unix or OSX. But I do think it's the right goal to aim for for any cases where using "the system Python" is the wrong answer.
One thing I *would* suggest is that a lot of "corporate" use of Python (by which I mean semi-informal scripting and automation done as part of the infrastructure of larger projects written in more "enterprise" tools like Java or higher level CRM/eBusiness/etc packages) is not suitable for a curated stack (corporate IT policies would see that as a "3rd party tool" where the python.org distribution is just a project-internal utility). But the staff involved are typically not familiar with open source or its culture, and struggle to deal with things like package management (this is *not* the "legal approval" issue, as cut and paste of code from websites is common in this culture - it's "internal use only"). Within the context of your two categories, this may well be a third one (unless you stretch "application developers" way beyond what I think you are intending).
No, that is the case covered by 'creators of corporate "Standard Operating Environment" definitions'. That's explicitly in the software integrator category - whether those users formally have the responsibility of defining an SOE, that's what they're doing in practice.
OK. In which case that category is far broader than I anticipated, and includes people who cannot even write a Windows batch file or use a command line without instruction (I can name names!!! ;-)) If that's your view, though, then all I can say is that I have no experience of anyone who isn't in the "software integrator" category, so I'll take your word that there is only one other category :-) Paul