Support any URL (including file:///) if it has an author in it? about app-cpanminus-reporter HOT 9 CLOSED

I notice that right after checking the protocol, cpanminus-reporter checks to see if it can find the author name from the URL:

https://github.com/garu/App-cpanminus-reporter/blob/master/lib/App/cpanminus/reporter.pm#L314

If that check is robust enough, perhaps it is enough to just add 'file' as an acceptable protocol?

from app-cpanminus-reporter.

I see no reason not to allow file:///

from app-cpanminus-reporter.

I don't know guys... I'm afraid it could do more harm than good. Perhaps we can make a more robust solution, like checksumming of the local repository tarball and comparing it to the CPAN version. Or am I being too much of a purist here?

from app-cpanminus-reporter.

summoning @dagolden for an opinion about reporter purity :)

On Mon, Jan 5, 2015 at 8:49 AM, Breno G. de Oliveira <
[email protected]> wrote:

I don't know guys... I'm afraid it could do more harm than good. Perhaps
we can make a more robust solution, like checksumming of the local
repository tarball and comparing it to the CPAN version. Or am I being too
much of a purist here?

—
Reply to this email directly or view it on GitHub
#15 (comment)
.

from app-cpanminus-reporter.

My problem with a purity argument is that all of the arguments against using file:// also apply to http://.

As an example, if someone configures the use of an official CPAN mirror that later is retired (but maintains its old files), you have a problem. Or if that mirror is hacked to include bogus files. It doesn't have to be an official CPAN mirror it could be an organizations mirror. Or like me, at home I maintain a minicpan mirror served via http which serves a number of virtual hosts that I use for testing. Please explain to me how any of these scenarios are fool proof?

Based on my experience as a CPAN author, the universe of cpan testers is pretty small and they are sophisticated enough to understand these issues.

In the very least a --please-allow-file-urls-i-promise-to-keep-my-mirror-up-to-date option would be helpful. It would in the least force the user to read some documentation and give you the opportunity to educate on the dangers (such as they are). Such an option doesn't seem to me to be any less dangerous than the --force option. Having read the documentation I know to use it with care.

from app-cpanminus-reporter.

Support for file:// url would be really useful for me. In fact I have to apply a patch to my laptop systems, but I'd love to be able to just use the version out of cpan without patching.

Can we please get this as an option at least? I can open a PR with documentation for such an option if there is a concern. I think just supporting file:// is the best way to go.

from app-cpanminus-reporter.

@garu would you please consider allowing file URLs? It is aggravating to have to patch cpanminus-reporter. As mentioned before:

• Such URLs will only work in a mirror of CPAN since there are checks immediately after to ensure that a username can be determined from the URL
• The argument that the mirror might be out of date is bogus, because an http or ftp mirror could also be out of date.

Please at least add an option that allows an option to allow file URLs. Displaying an error message when a file URL is attempted without the option explaining the dangers (however slim) involved in using a file URL could thus be averted by conscientious users.

from app-cpanminus-reporter.

Re support for file schema, see #29

from app-cpanminus-reporter.

DONE! Thanks everyone, sorry it took so long. Yay for PTS 2023 \o/

from app-cpanminus-reporter.