-
Notifications
You must be signed in to change notification settings - Fork 13
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
Support any URL (including file:///) if it has an author in it? #15
Comments
I notice that right after checking the protocol, 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? |
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? |
summoning @dagolden for an opinion about reporter purity :) On Mon, Jan 5, 2015 at 8:49 AM, Breno G. de Oliveira <
|
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 |
I see no reason not to allow file:/// |
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. |
@garu would you please consider allowing file URLs? It is aggravating to have to patch cpanminus-reporter. As mentioned before:
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. |
Re support for |
DONE! Thanks everyone, sorry it took so long. Yay for PTS 2023 \o/ |
Similar to #13 -- would it be possible to support sending reports for any source URL, as long as it is in the form of
G/GA/GARU/App-cpanminus-reporter-0.123.tar.gz
(or even justGARU/App-...
)? This would make it possible for reports to be sent for local archived tarballs, as long as they were organized into the proper directory structure.It would also let me eliminate this nasty hacky code :) -- https://metacpan.org/source/ETHER/Dist-Zilla-PluginBundle-Author-ETHER-0.069/lib/Dist/Zilla/PluginBundle/Author/ETHER.pm#L250
The text was updated successfully, but these errors were encountered: