[Tutor] IOError when importing nose

Walter Prins wprins at gmail.com
Mon Jul 15 17:41:29 CEST 2013


Hi,

On 15 July 2013 12:08, Albert-Jan Roskam <fomcl at yahoo.com> wrote:

> > From: Japhy Bartlett <japhy at pearachute.com>
> >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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20130715/b2f509f1/attachment.html>


More information about the Tutor mailing list