[chef] COOK-3084 CFV


Chronological Thread 
  • From: Alex Kiernan < >
  • To:
  • Subject: [chef] COOK-3084 CFV
  • Date: Wed, 12 Jun 2013 09:28:39 +0100

I want to move COOK-3084 on - I'll summarise then ask for a vote.

To summarise, as it is today the virtualenv provider in the python cookbook when used on EL5 and the (default) package style installation requires you to set the interpreter attribute or it will use the wrong python, i.e. you must write something like:

python_virtualenv "cook-3084" do
  # on EL5 the default python we install is called python26
  if !node['python']['install_method'].eql?("source") &&
     platform_family?('rhel') &&
     node['platform_version'].split('.').first.to_i < 6
    interpreter '/usr/bin/python26'
  end
end

If you want to portably consume the virtualenv provider. The reason this is the case is because the code today gratuitously passes in the --python argument to virtualenv and hardcodes it to `python' which is incorrect for the virtualenv which pip has previously installed.

I've one branch - https://github.com/akiernan/python/tree/add-venv-tests which adds test kitchen tests which include exactly this test. In order to change the code so that a green test can be written as:

python_virtualenv "cook-3084" do
end

I have three branches which allow this test to pass:


The first leaves almost everything as is, but ensures the same binary as was used to install pip is passed to the --python argument if the interpreter attribute is not specified.

The second ensures that --python is only passed into the virtualenv invocation if the consumer has explicitly specified it.

The third removes the interpreter attribute entirely and requires that if --python is required then it is passed in through the options attribute.

I've no more code to push and have run all 4 branches through test kitchen successfully.

Where I believe we are is:

--
Alex Kiernan



Archive powered by MHonArc 2.6.16.

§