Cook-3084 cfv

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:

  1. https://github.com/akiernan/python/tree/handle-rhel5 (
    https://github.com/akiernan/python/compare/master...handle-rhel5)
  2. https://github.com/akiernan/python/tree/avoid-venv-python (
    https://github.com/akiernan/python/compare/master...avoid-venv-python)
  3. https://github.com/akiernan/python/tree/remove-interpreter (
    https://github.com/akiernan/python/compare/master...remove-interpreter)

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:

  1. https://github.com/akiernan/python/tree/handle-rhel5 (
    https://github.com/akiernan/python/compare/master...handle-rhel5)

-1 Noah
-1 Steven
+1 Mike

  1. https://github.com/akiernan/python/tree/avoid-venv-python (
    https://github.com/akiernan/python/compare/master...avoid-venv-python)

+1 Steven

  1. https://github.com/akiernan/python/tree/remove-interpreter (
    https://github.com/akiernan/python/compare/master...remove-interpreter)

-1 Mike

Please can we vote across the three options?


Alex Kiernan

Hi Alex,

First off, awesome work, on all fronts.

I have reviewed all of the options you presented, and am now coming
around to realizing that option #2 (herein "avoidance") is most
probably the "best" thing to move forward with.

Concerns raised previously:

  • Backwards compatibility
    It looks as if a user has needed to use 'python26' on RHEL5-style in
    previous versions of this cookbook, they would have handled it
    themselves with a specific LWRP override.
    This change means that their override will still work, but will
    probably be unnecessary.

  • Attribute re-use in provider
    Steven had raised a concern about attributes being used in the
    Provider, not used here.

I am now of the opinion that the "avoidance" method is the right way
to go, and this is possibly still in the realm of a Minor version.

So in short, that's +1 from me for avoidance (option #2).

-Mike

On Wed, Jun 12, 2013 at 4:28 AM, Alex Kiernan alex.kiernan@gmail.com wrote:

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:

  1. https://github.com/akiernan/python/tree/handle-rhel5
    (https://github.com/akiernan/python/compare/master...handle-rhel5)
  2. https://github.com/akiernan/python/tree/avoid-venv-python
    (https://github.com/akiernan/python/compare/master...avoid-venv-python)
  3. https://github.com/akiernan/python/tree/remove-interpreter
    (https://github.com/akiernan/python/compare/master...remove-interpreter)

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:

  1. https://github.com/akiernan/python/tree/handle-rhel5
    (https://github.com/akiernan/python/compare/master...handle-rhel5)

-1 Noah
-1 Steven
+1 Mike

  1. https://github.com/akiernan/python/tree/avoid-venv-python
    (https://github.com/akiernan/python/compare/master...avoid-venv-python)

+1 Steven

  1. https://github.com/akiernan/python/tree/remove-interpreter
    (https://github.com/akiernan/python/compare/master...remove-interpreter)

-1 Mike

Please can we vote across the three options?

--
Alex Kiernan