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

fork() before reporting tests [rt.cpan.org #60663] #58

Open
xdg opened this issue Apr 3, 2016 · 1 comment
Open

fork() before reporting tests [rt.cpan.org #60663] #58

xdg opened this issue Apr 3, 2016 · 1 comment
Labels

Comments

@xdg
Copy link
Contributor

xdg commented Apr 3, 2016

https://rt.cpan.org/Ticket/Display.html?id=60663

When installing a big wad of CPAN modules, reporting the test results
slows things down.  I figured it was the process of sending an email,
but it seems even the new Metabase system has a delay.  Not nearly as
bad as it was with email, but this can get really bad on a dodgy network
the result being that for big builds I'll turn it off.

Since reporting a test has no effect on the install process it could be
done in the background while CPAN.pm goes about its business.

There's no need to inform the user of a successful report, but telling
them about a problem becomes a... problem.  How the subprocess
communicates with the parents is a SMOP, but wedging the information
into the CPAN interface isn't.  Any problems could be reported as part
of the end-of-command summary that normally reports any problems with
installing modules.  This would require the end of summary waiting for
the children to finish which, in the worst case, is no worse than were
it is now.

Good idea?
@xdg xdg added the wishlist label Apr 3, 2016
@jkeenan
Copy link
Contributor

jkeenan commented Sep 16, 2023

https://rt.cpan.org/Ticket/Display.html?id=60663

When installing a big wad of CPAN modules, reporting the test results
slows things down.  I figured it was the process of sending an email,
but it seems even the new Metabase system has a delay.  Not nearly as
bad as it was with email, but this can get really bad on a dodgy network
the result being that for big builds I'll turn it off.

Since reporting a test has no effect on the install process it could be
done in the background while CPAN.pm goes about its business.

There's no need to inform the user of a successful report, but telling
them about a problem becomes a... problem.  How the subprocess
communicates with the parents is a SMOP, but wedging the information
into the CPAN interface isn't.  Any problems could be reported as part
of the end-of-command summary that normally reports any problems with
installing modules.  This would require the end of summary waiting for
the children to finish which, in the worst case, is no worse than were
it is now.

Good idea?

This feature request was originally filed in RT back in 2010. There's been no further discussion since then. My hunch is that the effort involved in implementing this feature would be greater than the benefit, especially with newer versions of CPAN::Reporter, faster machines, etc.

So unless @schwern or someone else wants to pursue the matter further, I recommend this ticket be closed.

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

No branches or pull requests

2 participants