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

Wrong distname error not handled graciously #6

Open
xenoterracide opened this issue Jul 17, 2013 · 10 comments
Open

Wrong distname error not handled graciously #6

xenoterracide opened this issue Jul 17, 2013 · 10 comments

Comments

@xenoterracide
Copy link

Use of uninitialized value $_[0] in join or string at /home/xenoterracide/perl5/perlbrew/perls/perl-5.18.0/lib/5.18.0/x86_64-linux/File/Spec/Unix.pm line 86.

Failed to find shared file 'svc.paperlesstrans.wsdl' for dist 'Business-OnlinePayment-PaperlessTrans' at /home/xenoterracide/perl5/perlbrew/perls/perl-5.18.0/lib/site_perl/5.18.0/File/ShareDir/ProjectDistDir.pm line 211.

Not sure why, this only happens when run using make test normal prove -lvr works fine. Didn't have this problem previously.

https://github.com/xenoterracide/Business-PaperlessTrans

sharedir is loaded and used in Business::PaperlessTrans::Client

(note: tests under which it occurs do not run without credentials, could probably write one for you, also calling the attributes directly would do it )

@kentfredric
Copy link
Member

Its possible that for some reason its dist/not a dist heuristic is failing. Most likely causes for that failing are share dirs in unexpected places.

Also, can you post output given with

export FILE_SHAREDIR_PROJECTDISTDIR_DEBUG=1

?

Also, which version are you using thats exhibiting this, because I can't see how

# https://metacpan.org/source/KENTNL/File-ShareDir-ProjectDistDir-0.4.4/lib/File/ShareDir/ProjectDistDir.pm#L221
return $string_method if not $pathclass;

would cause that.

Additionally, if you get bored, theres a 0.5 release that tries to change the internals to work in terms of the (new) Path::IsDev and Path::FindDev tools.

https://metacpan.org/release/KENTNL/File-ShareDir-ProjectDistDir-0.5.0-TRIAL

Though this is still very experimental.

@xenoterracide
Copy link
Author

[ProjectDistDir] Working on: /home/xenoterracide/Documents/Business-PaperlessTrans/.build/5nfbMRfZz5/blib/lib/Business/PaperlessTrans/Client.pm
[ProjectDistDir] Trying to find parent 'lib'
[ProjectDistDir] Found lib : /home/xenoterracide/Documents/Business-PaperlessTrans/.build/5nfbMRfZz5/blib/lib
[ProjectDistDir] ISPROD: does not exist : lib/../share > /home/xenoterracide/Documents/Business-PaperlessTrans/.build/5nfbMRfZz5/blib/share
[ProjectDistDir] Working on: /home/xenoterracide/Documents/Business-PaperlessTrans/.build/5nfbMRfZz5/blib/lib/Business/PaperlessTrans/Client.pm
[ProjectDistDir] Trying to find parent 'lib'
[ProjectDistDir] Found lib : /home/xenoterracide/Documents/Business-PaperlessTrans/.build/5nfbMRfZz5/blib/lib
[ProjectDistDir] ISPROD: does not exist : lib/../share > /home/xenoterracide/Documents/Business-PaperlessTrans/.build/5nfbMRfZz5/blib/share
[ProjectDistDir] Working on: /home/xenoterracide/Documents/Business-    PaperlessTrans/.build/5nfbMRfZz5/blib/lib/Business/PaperlessTrans/Client.pm
[ProjectDistDir] Trying to find parent 'lib'
[ProjectDistDir] Found lib : /home/xenoterracide/Documents/Business-PaperlessTrans/.build/5nfbMRfZz5/blib/lib
[ProjectDistDir] ISPROD: does not exist : lib/../share > /home/xenoterracide/Documents/Business-PaperlessTrans/.build/5nfbMRfZz5/blib/share
[ProjectDistDir] Working on: /home/xenoterracide/Documents/Business-PaperlessTrans/.build/5nfbMRfZz5/blib/lib/Business/PaperlessTrans/Client.pm
[ProjectDistDir] Trying to find parent 'lib'
[ProjectDistDir] Found lib : /home/xenoterracide/Documents/Business-PaperlessTrans/.build/5nfbMRfZz5/blib/lib
[ProjectDistDir] ISPROD: does not exist : lib/../share > /home/xenoterracide/Documents/Business-   PaperlessTrans/.build/5nfbMRfZz5/blib/share
 Use of uninitialized value $_[0] in join or string at /home/xenoterracide/perl5/perlbrew/perls/perl-5.16.3/lib/5.16.3/x86_64-linux/File/Spec/Unix.pm line 86.
 Failed to find shared file 'svc.paperlesstrans.wsdl' for dist 'Business-OnlinePayment-PaperlessTrans' at /home/xenoterracide/perl5/perlbrew/perls/perl-5.16.3/lib/site_perl/5.16.3/File/ShareDir/ProjectDistDir.pm line 211.
 # Tests were run but no plan was declared and done_testing() was not seen.

sorry about the spaces in the middle of some of the lines, those were added by me making this code formated (really need to readd my prepend spaces function to my shell)

@kentfredric
Copy link
Member

On GH Markdown, you can use ``` as a code markup, so you don't need to add indentation to make it format.

ie:

```perl
blah use Class::Name qw(foo);
my $foo = blah();
```

-->

blah use Class::Name qw(foo);
my $foo = blah();

@xenoterracide
Copy link
Author

oh well that's cool, also boo markdown varieties, I don't think it particularly hurts readability, there are no spaces in the path, ever.

I would say though that the problem is it's looking at:

.build/5nfbMRfZz5/blib/share

instead of

.build/5nfbMRfZz5/blib/lib/auto/share/dist/Business-PaperlessTrans/

@kentfredric
Copy link
Member

This line is indicative:

[ProjectDistDir] ISPROD: does not exist : lib/../share > /home/xenoterracide/Documents/Business-   PaperlessTrans/.build/5nfbMRfZz5/blib/share

I'm trying to remember how this part of the system works on EUMM, whether File::ShareDir::Install is supposed to create an "installed" path locally somehow ( ie: share should be copied into blib/ somewhere as a mock installation step prior to installing to $PREFIX ), or whether it does it after/during the make install target.

Either way, its hitting blib/lib, and assuming $PROJECTROOT is blib and as such, is expecting the presence of blib/share to determine if this is an "installed" or "source" dist, so falling back to vanilla File::ShareDir behaviour, which expects to find the files somewhere inside @INC.

make test differs from prove in that

  • Filesystem layout of modules used is different
  • @INC is different.

It should still be able to work, but I just need a better look at it.

@kentfredric
Copy link
Member

.build/5nfbMRfZz5/blib/share

instead of

.build/5nfbMRfZz5/blib/lib/auto/share/dist/Business-PaperlessTrans/

Yeah, exactly, however, the place your error comes from appears to be this code if I'm not wrong?

  if ( not $distname ) {
    my $string_method = \&File::ShareDir::dist_file;
    return $string_method if not $pathclass;
    return sub { Path::Class::File->new( $string_method->(@_) ) };
  }

So here, its in File::ShareDir fallback mode ( as it should be ), and the error seems to be propaged from Path::Class being passed an invalid path for "some reason", which suggests File::ShareDir::dist_dir(@_) is returning undef, or something equally sinister.

@kentfredric
Copy link
Member

Sorry if I'm debugging via a long tube, stuck on windows away from my dev space for a little while, can't reboot just yet, so trying to make what progress I can in the interim.

You could try

-use File::ShareDir::ProjectDistDir ':all', defaults => { pathclass => 1 };
+use File::ShareDir qw(:all);

And although like that it won't work under prove any more, it should still work under make test, and what it does there might be a good indication of whats going wrong. If it works fine there, then my code is to blame, and if it doesn't work there, the error it gives as to why is hopefully useful.

@xenoterracide
Copy link
Author

It appears to still be a problem with File::ShareDir itself

@xenoterracide
Copy link
Author

I have found the source of my issue, it's a PEBCAK, this dist got renamed when I split it from the B:OP module. I still had the old dist name coded in... (I think this goes back to me wanting to be able to use module_file at one point so I could have it with __PACKAGE__ instead of hard coding the dist name ). ugh, closing and sorry for wasting your time.

@kentfredric
Copy link
Member

No no, don't worry, its still a legitimate concern for me, it means I need better error handling somewhere still, even if its not my module at fault, I need better ways to easily diagnose common fault types. Now I know there's a bad error handling when a PACKAGENAME is wrong, I can start looking for ways to fix that.

After all, encapsulation rules dictate that even if a dependency of an encapuslated component is to blame, people using the API shouldn't be worrying about the implementation details, they should only worry about the interface the API provides.

So an encapsulation should either aim to solve a problem in a dependency, or push for fixes in the dependency.

@kentfredric kentfredric reopened this Jul 19, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants