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 [email protected].
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.
