Bug #619
A module is not found if it is not in the first existing path in modulepath
| Status: | Closed | Start date: | ||
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | % Done: | 0% |
||
| Category: | - | |||
| Target version: | - | |||
| Affected Puppet version: | 0.25.4 | Branch: | ||
| Keywords: | ||||
| Votes: | 0 |
Description
Modules.find appears to return the first found module dir, which may or may not include the module being looked for. If the module is instead in a later path, then the module is considered missing, even when it’s present.
History
Updated by David Lutterkort about 5 years ago
I don’t fully understand what you are saying; are you saying that if you have something like
DIR1/
.. no foo/ subdir ..
DIR2/
foo/
and a modulepath of DIR1:DIR2 something like “import ‘foo’” fails ? I just tried that with 0.22.4, and it seems to work. Note that the paths on modulepath must be absolute, otherwise they’ll be ignored in Puppet::Module::modulepath.
Or are you talking about a situation where both DIR1 and DIR2 have a foo subdir ? Not sure what should happen in that case; in my mind you have two different modules with the same name then.
Updated by Luke Kanies about 5 years ago
I’m getting somewhat inconsistent results, but here’s what I have:
test.pp:
#!/usr/bin/env puppet import 'modtest' include modtest
~/tmp/modtest:
luke@culain(0) $ find tmp/modtest/
tmp/modtest/
tmp/modtest/modules1
tmp/modtest/modules2
tmp/modtest/modules2/modtest
tmp/modtest/modules2/modtest/manifests
tmp/modtest/modules2/modtest/manifests/init.pp
luke@culain(0) $ cat tmp/modtest/modules2/modtest/manifests/init.pp
class modtest {
exec { "/bin/echo testing": }
}
luke@culain(0) $
Commands:
luke@culain(0) $ puppet --modulepath ~/tmp/modtest/modules1:~/tmp/modtest/modules2 bin/test.pp No file(s) found for import of 'modtest' at bin/test.pp:5 luke@culain(1) $ puppet --modulepath ~/tmp/modtest/modules2 bin/test.pp notice: //modtest/Exec[/bin/echo testing]/returns: executed successfully luke@culain(0) $ puppet --modulepath ~/tmp/modtest/modules2:~/tmp/modtest/modules1 bin/test2.pp notice: //modtest/Exec[/bin/echo testing]/returns: executed successfully luke@culain(0) $
I get this behaviour on OS X, Debian, and CentOS. I got some inconsistent behaviour when testing as root vs a normal user on CentOS using more complete configurations and default module paths, but the above should be sufficient to show that it’s a bug.
Updated by Luke Kanies about 5 years ago
- Status changed from 1 to Closed
- 7 set to worksforme
This is my user error; there were stub directories in the first directory in the module path that I didn’t know about during my tests and didn’t think to check. Duh.
Updated by Bryan McLellan about 4 years ago
Or are you talking about a situation where both DIR1 and DIR2 have a foo subdir ? Not sure what should happen in that case; in my mind you have two different modules with the same name then.
It appears to load whichever module is found first, even if the module directory is incomplete.
bryanm@prod-ops01:~/tmp$ find . . ./mod1 ./mod1/modtest ./mod2 ./mod2/modtest ./mod2/modtest/manifests ./mod2/modtest/manifests/init.pp ./test.pp
bryanm@prod-ops01:~/tmp$ puppet --modulepath /home/bryanm/tmp/mod1:/home/bryanm/tmp/mod2 test.pp Could not parse for environment development: No file(s) found for import of 'modtest' at /home/bryanm/tmp/test.pp:5
bryanm@prod-ops01:~/tmp$ puppet --modulepath /home/bryanm/tmp/mod2:/home/bryanm/tmp/mod1 test.pp notice: //modtest/Exec[/bin/echo testing]/returns: executed successfully
Updated by Luke Kanies about 4 years ago
This is correct and desired behaviour.