python virtualenv module

[Jason Antman]

Hello, community,

I work for a python/Django shop (we run supposedly one of the largest
Django apps out there), and we're just starting to use Puppet for
handling python stuff (and hopefully application deploys, eventually).
We're currently using a hacked up version of Mozilla RelEng's excellent
and quite helpful python module to handle virtualenv creation and pip
package installation - but the module (or at least our version of it)
doesn't handle requirements files, and uses a define to pip install
packages, so a given package can only be installed in one venv on a node.

Is anyone aware of a better, more complete python/virtualenv module?
I've seen stankevich/python on the forge, which handles requirements
files but doesn't fix the issue with only being able to install a given
package once per node (which, AFAIK, can be fixed with a native provider
but not a defined type). If not, does anyone have interest in
collaborating or contributing to a more feature-complete
python/virtualenv module?

If anyone's interested in collaborating, or can suggest an existing
module (stankevich's? or moz releng?) to start with, I've spoken with
one of the pip/virtualenv maintainers and he's interested in finding
something suitable that could become the "official" module.

Thanks for any advice, input or suggestions,
Jason Antman
jantman

(ccing djmitche as I can't find a mozilla releng email list)

[Sirtaj Singh Kang]

On 11/2/2013 3:31 AM, Jason Antman wrote:
[snip]

> package installation - but the module (or at least our version of it)
> doesn't handle requirements files, and uses a define to pip install
> packages, so a given package can only be installed in one venv on a node.

I have a hacked-up python virtualenv module, since I hadn't seen any
when I started out. I got around the singleton define problem you've
outlined by adding an optional package name parameter, which defaults to
the name of the define. This way you can keep the old behaviour for
simple cases:

python::virtualenv::package {
'<packagename>':
venv => '<destination env>'
}

but in the case where you want the same package in two environments, you
use a globally unique resource name and use the optional param:

python::virtualenv::package {
'<env>-<packagename>':
venv => '<destination env>',
package_name => '<packagename>'
}

When these defines are called internally (as a side effect of installing
dependencies for an app, for example), I always use the latter format.

That doesn't fix the requirements.txt problem, of course. I've been
looking at that too, but I don't feel that a pure puppet DSL solution is
necessarily the right way to approach it. A custom ruby plugin might be
a better solution.

-Taj.

[Jason Antman]

Taj,

I've considered that option as well, but that prevents the
list-to-multiple-resources language functionality from working. i.e.

$requirements ['tox', 'pytest', 'coverage']
python::package { $requirements }

-jantman