Requirements not updated for pyvenv -- requires forceupdate

[siebrand]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.22.1
• Ruby: ruby 2.0.0p648 (2015-12-16) [x86_64-linux]
• Distribution: CentOS 7.9
• Module version: 6.0.0

How to reproduce (e.g Puppet code you use)

  file { '/opt/requirements.txt':
    ensure  => present,
    mode    => '0755',
    source  => 'puppet:///modules/venv/requirements.txt',
  }

  python::pyvenv { "${virtual_env}":
    ensure     => present,
    version    => '3.6',
    systempkgs => false,
    venv_dir   => "${virtual_env}",
  }

  python::requirements { '/opt/requirements/requirements.txt':
    virtualenv   => "${virtual_env}",
    pip_provider => 'pip3',
  }

What are you seeing

1. Virtual environment is created.
2. requirements.txt is not applied.

What behaviour did you expect instead

1. Virtual environment is created.
2. requirements.txt is applied.

Any additional information

• When setting forceupdate to true for python::requirements, the requirements file is applied. But it is applied every puppet run, and aside from this being noisy, with dependencies of packages, this may lead to future problems.
• I think there may be a bug in manifests/requirements.pp:

Now:

    $local_subscribe = File[$requirements]
  } else {
    $local_subscribe = undef
  }

I think that could be so that $local_subscribe is always set to File[$requirements]:

  }
  $local_subscribe = File[$requirements]

This fixed the issue for me, but I don't know what the rationale is behind the current behaviour...

[acullenn]

Experiencing the exact same issue, though it's worth noting that it only seems to occur on puppet 6.x hosts. When I run my bolt plan that leverages this module against a host with puppet 4.8 I do not encounter this issue.

Puppet: 6.18.0 (client) / 6.19.1 (bolt host)
Ruby: ruby 2.4.10p364 (2020-03-31 revision 67879) [x86_64-linux] (client) / ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19] (bolt host)
Distribution: CentOS 7.7
Module version: 6.0.0 / 6.1.0

Requirements file is not enforced, verbose puppet logs indicate python::requirements class never ran.

The fix @siebrand indicated worked for me as well. What's the purpose of setting subscribe to undef in this instance?

If there isn't one, I'm happy to open a PR for this fix. Tested against hosts running Centos 7.7, 7.9 and against Puppet Agent versions 4.8.2, 6.18.0

[siebrand]

I'm going to resolve to forking because I can't really wait for this to get attention. Could a committer please comment what the issue is with this ticket and the proposed solution? It's unknown to me how to try and get more attention for this ticket...

[smortex]

Hi @siebrand

It's unknown to me how to try and get more attention for this ticket...

The most efficient way to move on is probably to open a PR with a first commit that add a failing test that reproduce the problem you encounter. Then add a second commit to implement a fix.

This make it easier for contributors to reproduce the issue and tinker with the issue to fix it the best possible way.

Thanks!

[siebrand]

This make it easier for contributors to reproduce the issue and tinker with the issue to fix it the best possible way.

Thanks for your reply, @smortex. I understand that. I am however completely unfamiliar with testing for puppet classes. So I tried to analyze, and explain in my report as best as I could.

It's unknown to me how to try and get more attention for this ticket...

The most efficient way to move on is probably to open a PR with a first commit that add a failing test that reproduce the problem you encounter. Then add a second commit to implement a fix.

Isn't this what @acullenhms did in #619? It's been waiting for attention since 2021-08-27.

[acullenn]

Hey @siebrand - yeah this is what I was aiming to accomplish. I'm currently using a fork in which it works well.

I think the barrier was the issue @smortex was referring to - in which two pyvenvs cannot share the same requirements.txt. I think it's worth noting though that I encounter this with upstream and with my branch. I'm not sure how to resolve that issue. But setting the local subscribe to undef doesn't appear to matter, at least from my testing.