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

[Noah Kantrowitz < >]

So I was the one that objected. Basically you should almost never use that 
argument to venv. If you want virtualenv to use python26 by default, then you 
need to install it with python26. In general it is fragile at best to try and 
use virtualenv to operate on a different version than it was installed with. 
We use node['python']['binary'] to control how pip gets installed, and then 
pip is what installs venv, so at heart that is the thing you need to change. 
The correct fix in this case is to entirely remove the use of --python from 
the virtualenv code, and instead 1) allow the user to control which 
virtualenv binary is used and 2) add an opaque #options or #extra_arguments 
attribute to allow giving arbitrary overrides.

--Noah

On Jun 5, 2013, at 1:50 PM, Alex Kiernan wrote:

> Bringing this to the mailing list as requested...
> 
> The comments in the ticket seem to suggest folks think I'm trying to use 
> the interpreter attribute, I'm not...
> 
> If you specify a straight virtualenv:
> 
>   python_virtualenv "mine" do
>   end
> 
> on RHEL5 then the defaults in resources/virtualenv.rb:
> 
>   attribute :interpreter, :default => 'python'
> 
> mean that you end up pointing at /usr/bin/python (which is 2.4), not 
> /usr/bin/python26. This was a regression (for RHEL5 at least) introduced by 
> COOK-1415.
> 
> By contrast the code in recipes/package.rb:
> 
>   if platform_family?('rhel') && major_version < 6
>     include_recipe 'yum::epel'
>     python_pkgs = ["python26", "python26-devel"]
>     node.set['python']['binary'] = "/usr/bin/python26"
> 
> Explicitly chooses /usr/bin/python26 on RHEL5.
> 
> All I'm trying to do with the patch on COOK-3084 is ensure that the value 
> of python passed to the virtualenv is consistent.
> 
> There is a minor change in behaviour on other platforms in that previously 
> the virtualenv provider would pass --python=python whereas now it will pass 
> --python=/usr/bin/python.
> 
> In many ways, not passing --python in at all would seem more correct, but 
> that's not how the provider's ever worked - something like (untested):
> 
> 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
> diff --git a/resources/virtualenv.rb b/resources/virtualenv.rb
> index dcb282c..e9f7327 100644
> --- a/resources/virtualenv.rb
> +++ b/resources/virtualenv.rb
> @@ -28,7 +28,7 @@ def initialize(*args)
>  end
>  
>  attribute :path, :kind_of => String, :name_attribute => true
> -attribute :interpreter, :default => 'python'
> +attribute :interpreter, :kind_of => String
>  attribute :owner, :regex => Chef::Config[:user_valid_regex]
>  attribute :group, :regex => Chef::Config[:group_valid_regex]
>  attribute :options, :kind_of => String
> 
> 
> -- 
> Alex Kiernan

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail