I felt like I
put this aside without wrapping up my point of view, which is
unfair and impolite, so I'll try to do that (hopefully
respectively) now.
On 09/09/2012 02:18 AM, Pedro Melo wrote: Hi, On Sat, Sep 8, 2012 at 6:18 PM, sawyer x <xsawy...@gmail.com> wrote:On Sat, Sep 8, 2012 at 9:49 AM, Pedro Melo <m...@simplicidade.org> wrote:On Fri, Sep 7, 2012 at 11:47 AM, sawyer x <xsawy...@gmail.com> wrote: * the author can include that module as a dependency on his projects like he does with all the other CPAN dependencies.The second one is the most important to me. Just because it is a module that you might not use, it might be a module that is installed on your system as a direct dependency of other modules I have on CPAN.That's a terrible thing to do! Please, for the love of all that is good and holy, never put any project to depend on a personal distribution of your favorite modules. I will most likely refuse to use it entirely for that reason alone. Declare what you're using, not what you like to have installed!huhs?? I'm telling you that I'm reusing modules under A::M::something on other CPAN distributions. It's not a "personal distribution", I'm not depending any dist on my Task::BeLike::MELO. I just have small reuseable modules, that I don't think have a proper place on CPAN right now, that I want to use on other dists I do have on CPAN… It seems like we're discussing a few different situations, so here are my thoughts of them. Obviously you can ignore whatever doesn't apply to you. Also, when I say "useful" in context of "useful to others", please infer that I'm also adding the words "possibly", "perhaps", "hopefully" and the likes, not assuming that it definitely will, but that under the right (albeit perhaps very extreme) conditions, it might be useful to someone else. 1. Putting modules (My::Module) under the namespace Author::PAUSEID::My::Module - I think that's a bad idea. If My::Module is useful to anyone, it should be available under a sensible name, such as My::Module. 2. Putting modules (My::Module) under the proper namespace but enclosed within distribution of an author namespace (Author::PAUSEID::ModulesIUseOrWrote) - I think that's a bad idea, for two reasons. The first is that it forces the user to install more modules. In the case of Task::* it makes sense, but when it's not about a specific system (Catalyst, Dancer, Moose, WebGUI), you're just pushing more deps down someone's pipe. If it's for a system, simply use Task::*. The second reason is the other usage, which are personalized bundles. That's item 3. 3. Making personalized lists of modules we use, we like, we care for, etc. a la Task::BeLike::*, Dist::Zilla::PluginBundle::PAUSEID and so on - I think that's a bad idea. Personalized bundles are personal things. Although you can learn from them, they aren't meant for teaching, they are there because people want their own repo inside CPAN to put their personal preferences. While it's possible, I don't think that's a polite usage of this community resource. As I said previously, I'm also not the only asshole who thinks people should probably not do this. If in any way I completely missed what you're trying to do, by all means, accept my apology and completely ignore me. If they are worth using them in production, they might just be worthwhile for someone else. Separate them into proper namespaces and distributions and upload them for others to enjoy.Other use cases I have: Moo/Moose roles. I have a couple of roles that I reuse on a lot of projects, including some modules that eventually will be uploaded to CPAN. Are they worth moving to Moo(se)X::Roles::Something? Maybe they are, maybe they aren't. At this point I don't really know, and instead of polluting that namespace, I would upload them to my Author namespace, and use them as dependencies.If anyone would be able to use them, then YES, they are worth splitting into a role! DEFINITELY! Please do that! I will be happy to help! By providing a role, you're at least saying "hey, you can use this shit! It's for you too! I hope you find it useful, and if not... that's cool too!" -- That's a good reason right there. I won't go into the goodness of decoupling your code properly, which you already know and appreciate.This is the thing: they are worth splitting for me. I reuse them across dists. I'm pretty sure CPAN's approach is "I don't know (nor frankly do I care that much) if others find them useful, but I'm uploading them there just in case someone else does somehow" - unless I missed a board meeting. :)I don't know (nor frankly I do care that much) if others find them useful. I do. Thats why I think uploading them to A::MELO::Moo::Roles::Something seems to me a better solution. You never know if your nifty Moo role won't be very useful to someone, or inspire someone else to write some expansion/extension or even added features to Moo itself. I can, however, tell you that I would strictly forbid anyone at $work from using anything under an Author::* namespace, simply because it practically screams "butt out!" Imagine a CPAN distribution called Moose::Flavor::XSAWYERX. Wouldn't that be weird? You'd probably think "alright, so he has his own flavor, but why? Why is it useful? Why not an extension, a feature request, a role, a proper name?" - this are the same thoughts I'd have for any Author::MELO::Moo::Role::Specialized. "Flavor" actually turns out to be a bit nicer because I'm saying "this is my flavor", and not "this is mine", which is what Author::* namespace implies, even if that's not what you mean to imply. Yes and no, I suppose. Dist::Zilla is a context, and the author is also a context. Which do you prefer?Shouldn't those plugin bundles be better off in the Author namespace, given that they are personal preferences? I think that because you can prepare plugin bundles that are related to a subject such as "tests" or "web" or whatever (thus providing it a more finer-grained context), author-specific bundles should probably go into Author::* as you're suggesting. I agree with you on that. Then you get: Author::MELO::DistZillaPlugins and Dist::Zilla::PluginBundle::Tests. At least that's much cleaner. When I don't bitch about other peoples' suggestions, I use this list to ask for namespace ideas. I also ask projects if I want to add extensions or write a plugin. Also, I often talk to project devs about how good an extension or plugin would be. Then I get naming suggestions and feature suggestions, thus making sure I have both a good namespace and an extension worthy of it.CPAN is there to promote reuse. I have modules that I want to reuse but I don't know if they should be real full blown CPAN modules. So I uploaded them to my Author namespace, and reuse them on other modules.People can't depend on your test environment. That's why you give it a proper name if you want others to be able to use it.It's not a test environment. They are production modules, that I use on my own projects. I want to reuse them on several projects. I don't really care if others do, but I do want to reuse them. I'm giving it a name in the Author::MELO namespace because I don't want to pollute the other CPAN namespaces. I can say that I've only once or twice have seen anyone asked to change namespace to leave room for others. It usually doesn't happen so I wouldn't worry. LET US ENJOY YOUR FRUITS OF LABOR! :) True, but then again, CPAN is not a personal CPAN mirror.I could install a local CPAN mirror and inject them, but then, when I upload one app to dotcloud or some other app engine, I'm stuck, because the dependency is not on CPAN. In your case, it doesn't seem like you have very personal modules, you're just being polite and don't want to take up the production namespace. Like I said, don't worry about it, simply upload it. You can ask whatever project community related about naming conventions/suggestions/ideas and making sure you're not stepping on any toes. It's rare, but they'll still be delighted you're asking. You're right, it was a lousy argument. :) However, sometimes methodologies are good enough. The corollary to "just because it doesn't, doesn't mean it can't" is "just because it might, doesn't mean it will". That is, just because theoretically anything could be of some value to someone doesn't mean it really will be in practice. That's especially true about things we classify and brand as "ours" and "personal". Your case, I'm learning, is not the exact same thing. Your case is that you have things that probably will be useful to someone, and should definitely go on CPAN, and not in a personalized namespace. Dude, just because I'm a loud person doesn't mean you need to take this as the word. If that's what you want to do, go ahead. I won't have any animosity or dislike for you, don't worry. :)Well, I will not upload stuff to Author unless I see acceptance here, that goes without saying. I don't like that there isn't a solution using CPAN for this. It seems wasteful to me to use other stuff when CPAN already covers this. I simply gave my (loud) opinion. No, thank you. :)Thanks for the time you took to reply to me, appreciated. Have an awesome day, s. |
- Re: RFC: the Author:: namespace Leon Timmermans
- Re: RFC: the Author:: namespace John M. Gamble
- Re: RFC: the Author:: namespace Pedro Melo
- Re: RFC: the Author:: namespace Pedro Melo
- Re: RFC: the Author:: namespace Pedro Melo
- Re: RFC: the Author:: namespace Yanick Champoux
- Re: RFC: the Author:: namespace sawyer x
- Re: RFC: the Author:: namespace Pedro Melo
- Re: RFC: the Author:: namespace Pedro Melo
- Re: RFC: the Author:: namespace Smylers
- Re: RFC: the Author:: namespace Sawyer X
- Re: RFC: the Author:: namespace Eric Wilhelm