[chef] Re: Re: COOK-3084 - wrong python on RHEL5

[Mike < >]

From virtualenv help:

-p PYTHON_EXE, --python=PYTHON_EXE
                        The Python interpreter to use, e.g.,
                        --python=python2.5 will use the python2.5 interpreter
                        to create the new environment.  The default is the
                        interpreter that virtualenv was installed with


-1 for removal of the '--python' option and major version bump right
now. I'd add that as a branch slated for version 2.0.0 to be fixed
sometime in the future, when there are other big changes.

To Noah's point of installing/invoking virtualenv with the desired
binary, it seems that in order to make that work, this [1] method
would have to be updated to use the correct one, since currently it
will look for whichever it first finds in $PATH.
Not opposing the approach, but it's probably a larger scope than this
particular PR.

I think that having the python cookbook be opinionated about which
binary to use on RHEL5 in one instance, and not conforming to that is
probably a logical bug, and should be addressed to be in line with the
decision to use the resource's argument or the node attribute.

Q: Can you use node attributes in providers? When do they resolve, and
if a subsequent attribute is set later in the run, how does that
affect this?

If the answer is "it's all good and cool - setting
node['python']['binary'] in a role/env/override attribute later works
as expected", then I think I'm on board with the change.

[1]: 
https://github.com/opscode-cookbooks/python/blob/master/providers/virtualenv.rb#L62-L68

-Mike

On Thu, Jun 6, 2013 at 9:26 AM, Steven Danna 
<
 >
 wrote:
> On 6/5/13 1:50 PM, Alex Kiernan wrote:
>
>> diff --git a/providers/virtualenv.rb b/providers/virtualenv.rb
>> index dfd9f4e..addb724 100644
>> --- a/providers/virtualenv.rb
>> +++ b/providers/virtualenv.rb
>> @@ -29,7 +29,8 @@ end
>>  action :create do
>>    unless exists?
>>      Chef::Log.info("Creating virtualenv #{new_resource} at
>> #{new_resource.path}")
>> -    execute "#{virtualenv_cmd} --python=#{new_resource.interpreter}
>> #{new_resource.options} #{new_resource.path}" do
>> +    interpreter = new_resource.interpreter ? "
>> --python=#{new_resource.interpreter}" : ""
>> +    execute "#{virtualenv_cmd}#{interpreter} #{new_resource.options}
>> #{new_resource.path}" do
>>        user new_resource.owner if new_resource.owner
>>        group new_resource.group if new_resource.group
>>      end
>
> As I mentioned in the code review, I would be +1 on this as an
> intermediary step before the full fix.
>
>
> --
> Steven Danna
> Systems Engineer, Opscode, Inc
> GPG Key: http://stevendanna.github.com/downloads/code/public.key
>