Am Fr 09. Nov 2018, 13:14:10, REHSACK schrieb:
Show quoted text> On Fri Nov 09 12:56:08 2018, GUIDO wrote:
> > Am Fr 09. Nov 2018, 11:06:54, REHSACK schrieb:
> > > On Fri Nov 09 10:45:38 2018, GUIDO wrote:
> > Such directories can be removed or restored any time later. Likewise,
> > they may become unreadable, the x bit may be unset, and so on. There
> > are plenty of reasons why something can go wrong later.
>
> Sure. But you have one snapshot where it worked correctly - it was the
> time installing the module. So from there you can reconstruct ...
It always works correctly, whether the directory exists or not. A Unix user needs a home directory but it can be empty. In fact, not even the home directory has to exist.
Show quoted text> > Can you explain where you see an integrity issue if for example a
> > blind person removes their directory ~/Photos? Yes, sorry, but it
> > shows the point.
>
> In such a case the module wouldn't simply install without extra effort
> (disable tests) and the failing test explain what was missing.
"Failed test 'Our pictures directory exists'". I understood it after looking into the source code of the test.
Show quoted text>
> The module tests all it functions whether they work correctly or not.
> This ensures integrity of the implementation for the installed
> environment. Everything else would just be guessing ...
The test checks whether the returned string is the name of a directory. Following your logic you would have to test that it's also readable and writable.
Show quoted text> > A lot of these "standard" directories don't exist on my two machines,
> > a Mac and a Gentoo laptop. I have deleted those that I don't need,
> > and
> > the Gentoo installation was done so long ago, that these directories
> > had never been creaeted. I have never run into issues with that
> > because even software on the Mac simply prompts for another location
> > if the expected one is not available. And that's the way it should
> > be.
>
> Then it's good that you run into those issues now. Your dependency
> decided for File::HomeDir for a good reason (hopefully) and trusts
> whether it works correctly.
Dist/Zilla.pm:
require File::HomeDir;
my $homedir = File::HomeDir->my_home
or Carp::croak("couldn't determine home directory");
Where is the good reason?
https://metacpan.org/requires/distribution/File-HomeDir?p=1&size=500&sort=%5B%5B2%2C1%5D%5D
How many of these modules will not work if the user running it has no photos directory?
Show quoted text> > Furthermore, it is good practice to let _services_ run in as much
> > isolation as possible. It's certainly not bad practice to give system
> > users like "nginx" or "apache" their own private Perl environment.
> > But
> > does my nginx system user really need "~/My Music" or "~/My
> > Documents"?
>
> You shouldn't use File::HomeDir in a service which runs as an nginx
> service. That's insane. File::HomeDir is the wrong solution then.
See the reverse dependency list above. File::HomeDir is depended on by too many other modules for that argument.
Show quoted text> > Besides, the tests are run for the user that *builds* the software,
> > not the one that uses it. When I install File::HomeDir with sudo and
> > my vendor's Perl the tests succeed. When I install it with perlbrew
> > they fail.
>
> Without seeing the output and the tape archive of the tested
> environemnt, I can't say anything to that.
Run the test as root. It succeeds. But does your uid 0 have a photos directory?
Tests for Perl modules are run on the *build* system. In the vast majority of cases, end users never run these tests. They just use the installed software.
Show quoted text> > The concept of a home directory is a well established standard.
> > Dedicated directories for certain file types is nothing but a
> > convention. Not even Apple or Microsoft enforce that convention. Why
> > does a Perl module?
>
> Just because simply using $HOME is not enough. Showing the right name
> for Bilder (~/Photos) in i18n environments (or ~/Movies ...) is
> important. When you think you don't need all that Freedesktop
> specified locations, then File::HomeDir is the wrong answer for your
> question.
Look at the reverse dependencies. Most of them have nothing to do with desktop applications. They use use File::HomeDir for getting the home directory.
Show quoted text>
> Rethink your question, please.
I did.
My point is that these tests fail for conditions that are not errors at all. File::HomeDir provides a portable way to get the default locations for certain file types. If a software - whether it's using File::HomeDir or not - breaks just because such a location does not exist under certain conditions, then that software has a serious flaw. ENOENT and ENOTDIR are just two out of many error conditions and errors are there to be caught.
Maybe we just disagree? I also think that testing whether a file exists before opening it is a waste of time and a recipe for races. Then it's only natural that I don't see the point in testing whether a certain file exists on the build system for the build user at build time.
