Hi, On 15 July 2013 12:08, Albert-Jan Roskam <[email protected]> wrote:
> > From: Japhy Bartlett <[email protected]> > >I have to disagree with Walter about using system packages instead of > pip, though his advice is spot on for fixing this issue and he obviously > knows what he's doing. Very much my experience that pip is overwhelmingly > more popular and reliable. > > > >Something something virtualenvs. > > I was also somewhat surprised by that remark. Pip is better (newer) than > easy_install, and I always assumed that pip was at least as good as e.g. > apt-get. But that was just an assumption of mine, based on nothing really. > Well I did say "slightly", so YMMV. But, to elaborate and perhaps belabor the point: If a module is being installed system wide (as it was in this case), then I lean towards preferring wherever possible the OS package manager, so as to help maintain system integrity and avoid potentially breaking for example future automatic upgrades via the system package management system. This helps ensure that the package manager will continue to take care of actually updating all system wide packages on system including Python modules (think security patches and "rest of OS compatibility"), as well as to ensure that the system wide versions installed remains suitable/tested/compatible with other software installed on the operating system by the package manager or used by the OS, some of which may be relying on *particular* versions of the modules/packages. Imagine for example the kinds of trouble that might happen if you, say, install version 1.3 of some imaginary Python module "abc" via pip, and then later you innocently (try to) install what to you is an unrelated package manager software package "XYZ" which happens to also depend on version *1.1* of the Python module "abc"... Probably, the package manager will abort due to finding files already present, or it may just blindly overwrite your pip installed version. Neither option is obviously really a desirable outcome. Or imagine that your system happens to already have Python module "def" version 1.5 installed via package manager as a dependency of, say, some of the OS utilities on your system, and that then you go and upgrade or force-install say version 2.0 of module "def" system wide via pip, which then happens to change a bunch of class definitions/interfaces in the module, thereby breaking all the OS utilities that depend on this module. That would also probably be a painful mess to sort out... In short: If one makes changes/additions/deletions to system files outside of the package management system you in principle always run the risk of accidentally breaking or causing issues either immediately or down the line with future automatic package upgrades, as well as potentially causing problems if in future you try to install other software via the package management system that in turn depends on and then tries to automatically pull in the package manager version of the module that already installed "manually" via pip, etc. That's more or less the rationale. I should probably add for completeness sake (in lieu of the "Something something virtualenvs" comment), that if you're using virtualenv or any type of local/user based python setup/install then pip is obviously your only option. ;) ) Walter
_______________________________________________ Tutor maillist - [email protected] To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
