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

[Alex Kiernan < >]

I'll check the untested patch I posted... pretty sure it'll make an out of the box RHEL5 box do the right thing. Passing in --python by default seems wrong to me. Pushing it in via options if that's what you need seems reasonable.

Are we saying we want to remove the interpreter attribute entirely and bump the version to 2.0.0?

On Wed, Jun 5, 2013 at 10:05 PM, Noah Kantrowitz < " target="_blank"> > wrote:

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

--
Alex Kiernan