[chef] Re: COOK-3084 CFV

[Mike < >]

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 
<
 >
 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
>
> 2. https://github.com/akiernan/python/tree/avoid-venv-python
> (https://github.com/akiernan/python/compare/master...avoid-venv-python)
>
> +1 Steven
>
> 3. 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