Hello, thanks for this super-useful module. I'd like to make a change to this block here
https://github.com/stankevich/puppet-python/blob/0277b9c81f5838dce9353a0a87a7029b7ebcf397/manifests/requirements.pp#L92
...but have some questions about how to best solve it.
Here's the situation: we deploy a package ("coolstuff") that has its own requirements.txt, like so:
file { "/srv/coolstuff":
ensure => directory,
recurse => true,
source => "puppet:///modules/coolstuff/coolstuff",
}
python::virtualenv { "/srv/coolstuff_venv":
requirements => "/srv/coolstuff/requirements.txt",
require => File["/srv/coolstuff"],
}
Result: the block in requirements.pp, which as linked above has "replace => false", locks the requirements.txt down at whatever version first appeared. So if we update the file in the coolstuff module, that newer version never gets deployed.
The workaround is to make it explicit that we manage the file ourselves, ie we add:
file { "/srv/coolstuff/requirements.txt":
source => "puppet:///modules/coolstuff/coolstuff/requirements.txt",
}
but obviously that's a bit ugly.
Would there be any other way to detect that requirements.txt is managed elsewhere, or should I rather add an attribute "manage_requirements (true/false)" to python::requirements (and also to python::virtualenv) to prevent this manually?
(Frankly, I don't really see the use case where python::requirements should ever manage requirements.txt, so as far as I'm concerned, it should be fine if that whole block, L83-94, goes out altogether?)
Hello, thanks for this super-useful module. I'd like to make a change to this block here
https://github.com/stankevich/puppet-python/blob/0277b9c81f5838dce9353a0a87a7029b7ebcf397/manifests/requirements.pp#L92
...but have some questions about how to best solve it.
Here's the situation: we deploy a package ("coolstuff") that has its own requirements.txt, like so:
Result: the block in requirements.pp, which as linked above has "replace => false", locks the requirements.txt down at whatever version first appeared. So if we update the file in the coolstuff module, that newer version never gets deployed.
The workaround is to make it explicit that we manage the file ourselves, ie we add:
but obviously that's a bit ugly.
Would there be any other way to detect that requirements.txt is managed elsewhere, or should I rather add an attribute "manage_requirements (true/false)" to python::requirements (and also to python::virtualenv) to prevent this manually?
(Frankly, I don't really see the use case where python::requirements should ever manage requirements.txt, so as far as I'm concerned, it should be fine if that whole block, L83-94, goes out altogether?)