Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

virtualenv / systempkgs and fact precedence #94

Closed
riton opened this issue Jul 23, 2014 · 1 comment
Closed

virtualenv / systempkgs and fact precedence #94

riton opened this issue Jul 23, 2014 · 1 comment

Comments

@riton
Copy link
Contributor

riton commented Jul 23, 2014

On Centos 6, in a master/agent environment with this manifest

class { '::python':
        dev         => true,
        virtualenv  => true,
        gunicorn    => false
    }

    ->

    python::virtualenv { '/opt/python-xxx':
        ensure       => 'present',
        requirements => '/etc/xxx/requirements.txt',
        systempkgs   => true,
        owner        => 'root',
        group        => '0',
        cwd          => '/opt/python-xxx',
    }

executed on a machine without any previous installation of virtualenv, it seems that the fact virtualenv_version is empty (no way to get the virtualenv version since virtualenv is not yet installed when the fact is evaluated).

On Centos 6, this leads to the creation of a virtualenv without systempkgs. Since the virtualenv is created on the first puppet pass, it will never create the virtualenv with systempkgs.

riton added a commit to ccin2p3/puppet-python that referenced this issue Jul 23, 2014
As specified in voxpupuli#94, when their is no way to find virtualenv version,
fall back to user request.

When fact virtualenv_version is not yet available, stupidly trust user
input and force systempkgs options without taking care of virtualenv
veresion.

1. If the option choosen is not recognized by the installed version of
virtualenv, further Exec will fail and dependencies will not be processed.
2. On the next puppet execution, fact _virtualenv_version_ will be available and process should work as
expected.
@riton
Copy link
Contributor Author

riton commented Jul 28, 2014

Cool, thanks for merging this !

@riton riton closed this as completed Jul 28, 2014
shivapoudel pushed a commit that referenced this issue Sep 1, 2015
As specified in #94, when their is no way to find virtualenv version,
fall back to user request.

When fact virtualenv_version is not yet available, stupidly trust user
input and force systempkgs options without taking care of virtualenv
veresion.

1. If the option choosen is not recognized by the installed version of
virtualenv, further Exec will fail and dependencies will not be processed.
2. On the next puppet execution, fact _virtualenv_version_ will be available and process should work as
expected.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant