On 14 September 2016 at 08:55, Donald Stufft
Another problem, particularly on Windows, is going to be stuff like:
import someclibrary pip.install(“thing”) # Implicitly upgrades someclibrary
In this case, this would explode because Python will have the someclibrary.dll locked and the upgrade will attempt to remove it.
My fears here are that people are going to get really confused when they make state modifications to their Python environment and they don’t see those modifications reflected (because of sys.modules caching or what have you). You can possibly get around that with reload(), but we already know the problems that reload() has. Of course, that doesn’t stop Python from offering reload(), but I think the difference is that reload() is targeted towards people with weird edge cases who can understand the caveats while the hypothetical ``pip.install()`` is targeted towards people who are beginners who are still having problems figuring out the difference between the REPL and their shell, much less the vagaries of Python’s global state and attempting to modify that in a now running Python program.
While I'm normally not a fan, I think this is a case where a widely ignored warning is the most sensible option - if people see *any* kind of weirdness after doing a live package install, their first reaction should be to restart their Python environment and see if the problem goes away. In a lot of cases things will work fine (since a lot of modules are well-behaved in this regard), and for those that aren't, a restart is usually a sufficient remedial step. To further reduce the support footprint, we can explicitly limit this API to supporting installation using the *default* configuration settings only - absolutely no configurability whatsoever other than an optional version constraint on the package being installed. Since this is a new API, we could also make it only do --user installs when outside a virtual environment. That said, to fend off requests for increased complexity in the beginner focused `pip.install()` API, it may be necessary to finally define a semi-supported `pip._custom_install()` API that exposes more of the bells and whistles supported by `pip install`. The underscore prefix would clearly indicate the officially unstable nature of the API, and beginners are unlikely to reach for "pip._custom_install()" when "pip.install()" exists.
Perhaps a better idea would be to add some smarts to the REPL (but not to Python itself) that would detect something like:
pip install
And print a better error message that gives a better indication about what’s gone wrong besides a SyntaxError?
I filed http://bugs.python.org/issue28140 for that - we should be able to hook into the same system that gives special error messages for "print message" and "exec code" in Python 3. (The related special casing is actually in the SyntaxError constructor, so this would affect non-interactive code as well, but I think that's fine for this case). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia