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

False 'classname not in autoload module layout' now being thrown #140

Closed
mschuchard opened this issue Nov 7, 2017 · 6 comments
Closed

False 'classname not in autoload module layout' now being thrown #140

mschuchard opened this issue Nov 7, 2017 · 6 comments
Assignees

Comments

@mschuchard
Copy link
Member

@mschuchard mschuchard commented Nov 7, 2017

puppet-lint inside of linter-puppet-lint now throws a false classname not in autoload module layout when puppet-lint outside of it confirms nothing is wrong.

Test case:

  • any situation where the atom project is also the module
@mschuchard mschuchard self-assigned this Nov 7, 2017
@jeski
Copy link

@jeski jeski commented Jan 2, 2018

still a problem

@mschuchard
Copy link
Member Author

@mschuchard mschuchard commented Jan 3, 2018

Forgot about this while focusing on other projects. I have narrowed down the event that triggers this false warning (original issue updated) and feel like it is probably occurring due to some conflict Atom has with the new relative pathing code to respect the .puppet-lint.rc.

@mschuchard
Copy link
Member Author

@mschuchard mschuchard commented Jan 3, 2018

Ok, I took the exact command and directory passed into sb-exec and executed it from the shell. It did not duplicate this issue. Therefore, puppet-lint and this package are fine and the issue is with a dependency of this package. I do not see a way to circumvent the issue in the dependency, so we will have to wait until the bug is fixed in the dependency.

Issue will remain open until the dependency is fixed.

@fizmat
Copy link

@fizmat fizmat commented Oct 10, 2019

Is the upstream problem fixed? I had this linter error thrown at me and found this git issue.

But then I fixed it (at least for me) by adding the --relative flag. I think puppet-lint actually cares about the file locations relative to %modulepath without this flag?

Maybe the dependency problem got fixed, and the --relative flag was my unrelated issue, so this issue can be resolved.

Either way, a "relative" checkbox in plugin options would be nice, maybe even on by default (more likely the modules are edited on the developer's machine, not in place on the puppet server).

@mschuchard
Copy link
Member Author

@mschuchard mschuchard commented Oct 10, 2019

You actually may have found the root cause here. The dependencies attempt to do file pathing for the display by constructing relative paths regardless of whether they should or not. This caused a bug for my Terraform linter package where it would display blank paths for situations where the Atom project was also the module, and which I then had to circumvent. I have a strong suspicion your experiment has revealed it is the same cause of this error.

I will take a look into this soon.

@mschuchard
Copy link
Member Author

@mschuchard mschuchard commented Oct 10, 2019

Ok I think I will take the simple intrinsic solution/suggestion and add --relative to the default flags. This is safer than coding a workaround like I did for the Terraform linter when this issue arose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants