Writing scripts for non-developers, in an unmanaged environment (IT cant push a python install to the system) on windows means running pyinstaller et. al., on your script, if it has dependencies or not. Its not worth it to walk someone through a python install to run a script, let alone installing optional dependencies. For linux, you are not limited to the standard library, but what the distros have packaged - its easy enough to tell a typical non-developer linux user "apt install python python-twisted, then run the script".
For deployment to restricted environments, optional dependencies suggested by python-dev is unlikely to be installed either. Not that this matters, or would matter for years, because IME those environments have ancient versions of python that the developer is restricted to anyways. And environments with limited internet access ... Bandersnatch on a portable hard drive. Not to sound too crass, but there are only so many edge cases that a third party platform developer can be expected to care about (enough to bend over backwards to support). Putting a curated list of "These are good packages that solve a lot of problems that the stdlib doesn't or makes complicated" on python.org is a great idea. Building tooling to make those part of a default installation is not. > -----Original Message----- > From: Python-ideas [mailto:python-ideas-bounces+tritium- > list=sdamon....@python.org] On Behalf Of Paul Moore > Sent: Sunday, October 29, 2017 4:26 PM > To: Guido van Rossum <gu...@python.org> > Cc: python-ideas@python.org > Subject: Re: [Python-ideas] Defining an easily installable "Recommended > baseline package set" > > On 29 October 2017 at 18:56, Guido van Rossum <gu...@python.org> wrote: > > The two use cases you describe (scripters and teachers) leave me luke- > warm > > -- scripters live in the wild west and can just pip install whatever (that's > > what it means to be scripting) > > In my experience, "scripting" *does* include people for whom "being in > a standard Python distribution" is a requirement. > > Situations I have encountered: > > 1. Servers where developers need to write administrative or monitoring > scripts, but they don't control what's on that server. The Python > installation that comes by default is all that's available. > 2. Developers working in environments with limited internet access. > For example, my employer has a Windows (NTLM) proxy that pip can't > work with. Getting internet access for pip involves installing a > separate application, and that's not always possible/desirable. > 3. Developers writing scripts to be shared with non-developers. On > Unix, this means "must work with the system Python", and on Windows > "download and install Python from python.org" is typically all you can > expect (although in that case "install Anaconda" is a possible > alternative, although not one I've tried telling people to do myself). > > Nick's proposal doesn't actually help for (1) or (2), as the problem > there is that "pip install" won't work. And bundling a script with its > (pure Python) dependencies, for example as a zipapp, is always a > solution - although it's nowhere near as easy as simply copying a > single-file script to the destination where it's to be run. So these > situations don't actually matter in terms of the value of the > proposals being discussed here. But I did want to dispute the idea > that "scripters can just pip install whatever" is inherent to the idea > of being a scripter - my experience is the opposite, that scripters > are the people *least* able to simply pip install things. > > Paul > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
