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

Support any URL (including file:///) if it has an author in it? #15

Closed
karenetheridge opened this issue Aug 8, 2014 · 9 comments
Closed

Comments

@karenetheridge
Copy link
Contributor

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 just GARU/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

@plicease
Copy link
Contributor

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?

@garu
Copy link
Owner

garu commented Jan 5, 2015

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?

@karenetheridge
Copy link
Contributor Author

summoning @dagolden for an opinion about reporter purity :)

On Mon, Jan 5, 2015 at 8:49 AM, Breno G. de Oliveira <
notifications@github.com> 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)
.

@plicease
Copy link
Contributor

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.

@dagolden
Copy link

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

@plicease
Copy link
Contributor

plicease commented Feb 3, 2015

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.

@plicease
Copy link
Contributor

@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.

@jkeenan
Copy link
Contributor

jkeenan commented Dec 25, 2017

Re support for file schema, see #29

@garu
Copy link
Owner

garu commented Apr 30, 2023

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

@garu garu closed this as completed Apr 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants