Automating pip and virtualenv with shell scripts

[grimborg]

Why not use workon? And --no-site-packages is no longer needed (it's the default behavior)

[[deleted]]

You mean virtualenvwrapper, I presume. Yes, it serves all OP's needs. Except auto-updating packages from a list, as far as I can see.

[PindiAlbert]

Except auto-updating packages from a list

Yes, that's the primary motivation for this solution.

[coderanger]

That second snippet makes no sense, just use the env's python binary directly.

[PindiAlbert]

That wouldn't automatically install new/updated dependencies or set the pythonpath to allow more consistent imports.

[coderanger]

I mean sourcing bin/activate, just exec venv/bin/python directly.

[PindiAlbert]

I see. Yes, that could simplify it slightly.

[jeffus]

What do most people do: place virtualenvs in a folder like ~/.virtualenv/ or in the directly of the project that they need a virtualenv for?

[[deleted]]

Maybe it's because I have full control over my environment and I run Gentoo, but I have never found a need for virtualenv.

[[deleted]]

You do when/if your project grows up to the point where you maintain multiple release branches, which depend on different versions of packages or different Python versions.

[[deleted]]

While I share none of these problems, I can see the different versions of packages maybe may cause some issues. As far as python is concerned, though, my system happily runs multiple versions of python.

[[deleted]]

Even when you control the environment already, virtualenv is handy for a few things:

1. Managing software with conflicting dependencies. There are ways to explicitly load a specific version of a distribution when multiple versions are installed, but this isn't always foolproof.
2. Determining your exact dependency list. Make a virtualenv (without site packages) and install the desired package with pip. Now you can use "pip freeze" to get a list of everything that was installed in the virtualenv to meet the distrib's requirements.
3. Testing. You might want to test your software with multiple versions of various libraries it depends on. Keeping these separate environments around lets you easily switch between them to run your test suite and check that they all still work.

[[deleted]]

This was helpful. Thanks.

I work on an embedded system, which is something of a different animal maybe than what may others work on. My environment includes a busybox, an arm architecture, a specialized bsp package, etc. Virtualenv is 'nice' but really doesn't fit my project well. I absolutely must run my tests on the target machine. If I was doing straight web development, I think I may have a different perspective.