Bug #619

A module is not found if it is not in the first existing path in modulepath

Added by Luke Kanies about 5 years ago. Updated about 4 years ago.

Status:Closed Start date:
Priority:High Due date:
Assignee:Luke Kanies % 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.

Also available in: Atom PDF