Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Test-File-ShareDir CPAN distribution.

Report information
The Basics
Id: 84269
Status: rejected
Priority: 0/
Queue: Test-File-ShareDir

People
Owner: Nobody in particular
Requestors: ether [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.3.1
Fixed in: (no value)



Subject: original sharedirs are not searched first
The original versions of dist_dir() and module_dir() are not called first, to see if the directory exists -- therefore a tempdir is created even when it is not necessary, for example when running tests via Dist::Zilla (which copies sharedirs into the right place). I *think* all that is necessary is to do this in Test::File::ShareDir::TempDirObject: sub _module_tempdir { my ($self) = shift; + my $orig_dir = File::ShareDir::_module_dir_new($self); + return $orig_dir if defined $orig_dir; return $self->{module_tempdir} if exists $self->{module_tempdir}; $self->{module_tempdir} = $self->_tempdir->subdir('auto/share/module'); $self->{module_tempdir}->mkpath(); return $self->{module_tempdir}->absolute; } sub _dist_tempdir { my ($self) = shift; + my $orig_dir = File::ShareDir::_dist_dir_new($self); + return $orig_dir if defined $orig_dir; return $self->{dist_tempdir} if exists $self->{dist_tempdir}; $self->{dist_tempdir} = $self->_tempdir->subdir('auto/share/dist'); $self->{dist_tempdir}->mkpath(); return $self->{dist_tempdir}->absolute; }
On 2013-03-29 08:22:25, ETHER wrote:
Show quoted text
> The original versions of dist_dir() and module_dir() are not called
> first, to see if the directory exists -- therefore a tempdir is
> created even when it is not necessary, for example when running
> tests via Dist::Zilla (which copies sharedirs into the right
> place).
>
> I *think* all that is necessary is to do this in
> Test::File::ShareDir::TempDirObject:

This change would result in the "install" dirs shadowing the development dirs in the case you were developing "X" on a system where "X" is also installed.

Which would mean that, if "X" was installed, the sharedir contents in the development version of the dist would be ignored -> You would forever be accessing the wrong files.

So this is "by design", as you *never* want the "system sharedirs", you *only* want the sharedirs from the dist, and the tempdirs are created to simulate the system share dirs, just with the dists sharedir contents, so you *ALWAYS* want the tempdir and *NEVER* want the system ones.

er, and not to mention if your "system" install was a privelaged user, the code you're suggesting would try to install files from /share/  into the system share dir , which I really doubt any one wants either.

This module is to /simulate/ the effect of installing the sharedir, not to /actually install the contents into the system sharedir/

That would be bad.
On 2013-04-02 20:48:55, KENTNL wrote: Show quoted text
> This change would result in the "install" dirs shadowing the development dirs > in the case you were developing "X" on a system where "X" is also installed. > > Which would mean that, if "X" was installed, the sharedir contents in the > development version of the dist would be ignored -> You would forever be > accessing the wrong files. > > So this is "by design", as you *never* want the "system sharedirs", you > *only* want the sharedirs from the dist, and the tempdirs are created to > simulate the system share dirs, just with the dists sharedir contents, so you > *ALWAYS* want the tempdir and *NEVER* want the system ones.
Show quoted text
> er, and not to mention if your "system" install was a privelaged user, > the code > you're suggesting would try to install files from /share/ into the > system share > dir , which I really doubt any one wants either. > > This module is to /simulate/ the effect of installing the sharedir, > not to > /actually install the contents into the system sharedir/ > > That would be bad.
All good points! I definitely do not want to either: - use the last-installed version's data, or - actually install the test data. So I concede that this ticket is entirely wrong-headed, and everything works as designed. I humbly close this ticket, more enlightened than before.
On 2013-04-29 12:46:39, ETHER wrote: Show quoted text
> So I concede that this ticket is entirely wrong-headed, and everything > works as designed. > > I humbly close this ticket, more enlightened than before.
I should note that what I was driving at is: "Dist::Zilla "installed" the data for us into blib, so we should detect that, when possible, rather than duplicating this effort and using a tempdir to find the test data", but I can't think of any good way of telling the difference between a dzil-created blib data directory and a genuinely-installed-into-real-PMLIB data directory -- other than adding dzil-specific logic like checking $CWD =~ qr/\.build/deadbeef/, but that's just horrible, of course!

> I should note that what I was driving at is:
> "Dist::Zilla "installed" the data for us into blib, so we should
> detect that, when possible, rather than duplicating this effort and
> using a tempdir to find the test data", but I can't think of any
> good way of telling the difference between a dzil-created blib data
> directory and a genuinely-installed-into-real-PMLIB data directory
> -- other than adding dzil-specific logic like checking $CWD =~
> qr/\.build/deadbeef/, but that's just horrible, of course!

Hmm, I see what you're getting at now.

What you want is something similar to my bootstrap::lib enhancement that uses a built lib dir "somewhere" from a previous iteration of 'dzil build', however, you'd need something deeper, that uses a previous build, that was run to the point of './Build | make' in the work tree.

But as all successful test runs result in garbage collection, trimming their ./.build/DEADBEEF  dir, using ./.build/DEADBEEF for anything other than failure diagnosis or mid-test analysis of build-dist-state  proves to be not very helpful.

So indeed, Test::File::ShareDir can't really cater for this, because it would add a restriction on usage that you could only  'prove -bvr' on a *built* source tree after calling ./Build | make

Which would be less useful than it presently is =)

Though I guess I could TODO something that works like this:

1. During test, check parent path for a 't/' directory.
2. If there is a parent 't/' directory, check for an adjacent 'blib/' directory.
3. Maybe use that instead of mocking up a tempdir
4. Make the tempdir only if the above is false, and there's no share directory populated in the blib/ path

However, that would require the sharedirs installed to blib/  to even trigger that condition, and I'm not even sure that ever happens atm, I haven't really looked in that part of the deployment process =)