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) -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/527424AE.30902%40jasonantman.com. For more options, visit https://groups.google.com/groups/opt_out.
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. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/527494B5.60708%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
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
On 11/02/2013 01:59 AM, Sirtaj Singh Kang wrote:>
> 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.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/527553F9.8090801%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.