benvanstaveren / Mojolicious-Plugin-Authentication

A plugin to make authentication a bit easier
http://search.cpan.org/dist/Mojolicious-Plugin-Authentication/
Other
20 stars 17 forks source link

Weird dependencies #6

Closed andk closed 11 years ago

andk commented 12 years ago

Sorry for the intrusion, nothing fails, all's well, I'm just curious about the two *.PL scripts coming with the distro. Pleasse treat with low priority, it is not urgent at all.

I find in the uploaded package both a Makefile.PL and a Build.PL. While the reason for having both is not obvious, it's OK, it certainly does no harm to have both, the user has a choice and choice is good.

But looking into the Build.PL I find the dependency

"configure_requires" => { "ExtUtils::MakeMaker" => "6.30", "Module::Build" => "0.38" },

and looking into the Makefile.PL I find the dependency

"CONFIGURE_REQUIRES" => { "ExtUtils::MakeMaker" => "6.30", "Module::Build" => "0.38" },

So this quite amazes me, because now it seems the user has less choice than with only one build system because the dependencies tell him to have the infrastructure for both build systems in place to only use one of them.

I could imagine it is a Dist::Zilla bug, I don't know enough about it. If so, I would like to bring it to the attention of the Dist::Zilla people because this seems quite wrong.

Do you have an explanation/opinion?

Thanks,

benvanstaveren commented 12 years ago

Hiya,

I think it's a misconfiguration of my Dist::Zilla, I tell it to use MB but I think I didn't tell it not to use MakeMaker, I might change that but on the other hand, having both available is something that tends to happen at some point anyway if you install a decent amount of modules, so that's why I guess I never really noticed it :/

Now for the thousand-dollar question; what's the "common" opinion on this? Personally I don't mind having the infrastructure for both available (since it would happen "organically" sooner or later), but if it's something that people frown on I'll change it, otherwise I'm just going to leave it the way it is :)

Thanks for the tip though Andreas, first time I've noticed it actually (should tell you something about how often I actually look at the generated files for my own projects... bad bad me :/)

On 09/15/2012 06:22 PM, andk wrote:

Sorry for the intrusion, nothing fails, all's well, I'm just curious about the two *.PL scripts coming with the distro. Pleasse treat with low priority, it is not urgent at all.

I find in the uploaded package both a Makefile.PL and a Build.PL. While the reason for having both is not obvious, it's OK, it certainly does no harm to have both, the user has a choice and choice is good.

But looking into the Build.PL I find the dependency

"configure_requires" => { "ExtUtils::MakeMaker" => "6.30", "Module::Build" => "0.38" },

and looking into the Makefile.PL I find the dependency

"CONFIGURE_REQUIRES" => { "ExtUtils::MakeMaker" => "6.30", "Module::Build" => "0.38" },

So this quite amazes me, because now it seems the user has less choice than with only one build system because the dependencies tell him to have the infrastructure for both build systems in place to only use one of them.

I could imagine it is a Dist::Zilla bug, I don't know enough about it. If so, I would like to bring it to the attention of the Dist::Zilla people because this seems quite wrong.

Do you have an explanation/opinion?

Thanks,

— Reply to this email directly or view it on GitHub https://github.com/benvanstaveren/Mojolicious-Plugin-Authentication/issues/6.

andk commented 12 years ago

Ben van Staveren notifications@github.com writes:

I think it's a misconfiguration of my Dist::Zilla, I tell it to use MB but I think I didn't tell it not to use MakeMaker,

Sounds plausible indeed.

I might change that but on the other hand, having both available is something that tends to happen at some point anyway if you install a decent amount of modules, so that's why I guess I never really noticed it :/

Now for the thousand-dollar question; what's the "common" opinion on this? Personally I don't mind having the infrastructure for both available (since it would happen "organically" sooner or later), but if it's something that people frown on I'll change it, otherwise I'm just going to leave it the way it is :)

You will get very, very different opinions depending on who you ask. But I'm strictly for the minimalist approach. No pollution. If MakeMaker is good enough, I'd say use it and nothing else. It's correct that both are available quasi everywhere but a package maintainer is only responsible for one package installation, not for the organic whole that the end user may have or wish. Every installed bit counts and costs some amount of maintenance, so don't impose anyhing on anybody that's not strictly necessary. Please note that 0.38 is also much higher than needed. I tried your package with 0.3624 and could not notice anything missing. So I believe also for the version number it is polite to not specify anything higher than needed.

I just had this type of argument with Module::Build people and in the end we agreed not to agree. I don't want to start a holy war about it, I just would like to raise some consciousness about the value of resources.

Thanks for the tip though Andreas, first time I've noticed it actually (should tell you something about how often I actually look at the generated files for my own projects... bad bad me :/)

It's very similar for me, I guess it's only human. My package is good enough for me, so it surely is for everybody else:/

I could imagine it is a Dist::Zilla bug, I don't know enough about it. If so, I would like to bring it to the attention of the Dist::Zilla people because this seems quite wrong.

It seems that the idea to support both M:B and EU:MM in one package is not well supported by Dist::Zilla. While this is a pity, I would not count it as a bug, so probably will not bother them with this idea.

Thanks for the quick reply!

andreas

benvanstaveren commented 11 years ago

This one should've gotten fixed way long ago, I never got around to closing the issue >.>