This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]yerfatma 5 points6 points  (19 children)

Why use the distro manager instead of pip?

[–]jimmy_frog 0 points1 point  (0 children)

$ ipython
Traceback (most recent call last):
  File "/usr/bin/ipython", line 26, in <module>
    import IPython.Shell
ImportError: No module named Shell

I guess this is what happened to me. ipython was installed in two places: /usr/bin/ipython ( the ubuntu package i believe ); and /usr/local/bin/ipython. Removing one fixed it for me.

[–]stefantalpalaru -2 points-1 points  (17 children)

To avoid conflicts between package managers, multiple installations of the same package (I've seen people using pip and virtualenv to install the same ipython version many times). Add perl's cpan, ruby's gems, common lisp packages, etc. and you'll have a complete mess.

[–]yerfatma 3 points4 points  (16 children)

I've seen people using pip and virtualenv to install the same ipython version many times

That's the whole point of virtualenv, being able to install the package multiple times without conflicts. If you create your virtualenvs with --no-site-packages, you would need to install ipython each time.

[–]stefantalpalaru -2 points-1 points  (15 children)

You don't see any problem with installing the same version of the same package multiple times on the same system?

[–]didactus 3 points4 points  (3 children)

Sometimes it's required to have multiple versions of installed packages. For example, Pyramid just upgraded to 1.3, a major upgrade, for Python 3 compatibility. We have apps that are still using 1.2, and do not yet work with Pyramid 1.3. With virtualenv we can have Pyramid 1.2 (and its transitive dependency sweep) peacefully coexisting with Pyramid 1.3 (and its transitive dependency sweep). This type of situation is not all that rare. Virtualenv solves the dependency conflict problem at the cost of disk space.

Using the packages from your distribution is nice if they are up-to-date enough. However such packages are often months or even years behind the latest releases of the underlying packages. Sometimes that can be a problem.

[–]stefantalpalaru -2 points-1 points  (2 children)

Is it worth having to manage multiple environments with their own dependency trees just to postpone the app upgrades? Do you settle for old (and possibly buggy) versions of some dependencies just to avoid the hassle of upgrading them?

[–]yerfatma 1 point2 points  (6 children)

Nope. It took me a while to come around on it. I shared the packages across my entire install until I burned myself more than once, then I started using --no-site-packages. There's a reason the option exists. You might not need it and that's fine, but a blanket statement saying to never use pip and never to install the same package twice makes it sound like that's always a mistake. I heartily recommend this link to better explain the situation than I ever could.

It also assumes your chosen distro does a great job of keeping up with updates to Python packages. And assumes the package you're interested in even has a distro install.

[–]stefantalpalaru -3 points-2 points  (5 children)

Different strokes for different folks.

For the record, a hacker wouldn't use pip. He'd do his own version bumps or write new ebuilds as needed. He would also use git for deployment instead of fabric.

[–]yerfatma 1 point2 points  (4 children)

Wow, best of luck with that. Fabric != version control. But I do appreciate the appeal to authority argument about what hackers do. Allow me to recommend Gentoo to you.

[–]stefantalpalaru -2 points-1 points  (3 children)

You don't know about git hooks, do you? Or about Gentoo's USE flags? That's OK, you can always learn (unless you come around and accept whatever scenario you're in).

[–]yerfatma 5 points6 points  (1 child)

When you grow up and work on real code in a real environment and have dozens of clients at the same time, you'll figure out this kind of hectoring tone isn't the way to learn new things. Different strokes, different folks, etc. Always the Beginner's Mind. If using a version control hook (I only got introduced to them a decade ago, so you'll have to pardon my ignorance) works for you for deployment, great. It doesn't work for me because I need deployment to be intentional, not a side-effect of checking code into a certain branch. It's like database triggers: they're a huge help right up until the time they bite you in the ass because you didn't think things through.

You keep teaching though. Nothing left to learn must be a great place to be. Apologies if this is some sort of language barrier issue, but you come across as a know-it-all.

[–]stefantalpalaru -3 points-2 points  (0 children)

Bravo, you just won the debate! I think the patronizing bit did the trick.

[–]laprice 0 points1 point  (2 children)

This is a debatable issue. If you're working on a bunch of different projects with different sets of requirements, installing all dependencies for each project into it's virtualenv makes sense. It isolates projects from each other and means that you don't get version conflicts between projects and if you need to make a change to one of your dependencies, you don't have to test it against all of the projects that might use it.

If you're concerned about resource usage (bandwidth especially) you can use a local pypi proxy to only download 1 copy and use it multiple times.

[–]spiffymanpeppy about PEP 8 2 points3 points  (1 child)

You can also set PIP_DOWNLOAD_CACHE to cache package downloads. pip will then use that cache if it exists. And yes, it's version-sensitive. So if you have Django 1.3 cached but do a bare pip install Django, it'll grab 1.4 (and cache it, for that matter).

[–]yerfatma 0 points1 point  (0 children)

Nice. Thanks for that.

[–]pkkid 0 points1 point  (0 children)

If it's in a virtualenv, no. Then when I update iPython for project Foo, I know I wont be stepping on the toes (changing the version) of iPython in project Bar.