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.



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

 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.
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. :)

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.

Shouldn't those plugin bundles be better off in the Author namespace,
given that they are personal preferences?
Yes and no, I suppose. Dist::Zilla is a context, and the author is also a context. Which do you prefer?

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.



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

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! :)


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.
True, but then again, CPAN is not a personal CPAN mirror.

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 can skip indexing them on search/metacpan, or index them and not
include them on general search results. Make that opt-in.

You can more aggressively remove old versions. You can delete old
versions to Backpan. Or even send skip sending them at all to Backpan.

And you can skip them when you create your local CPAN mirror, pulling
only your own namespace.
All of this can be done, but none of it is, and probably none of it will be.
That's a lousy argument :)

With that atitude nothing will ever get done.Stuff get's done when
somebody is unhappy with something and has the access and time to do
it.
You're right, it was a lousy argument. :)

However, sometimes methodologies are good enough.


I still think this is an idea worth considering. You can see it as
just another garbage namespace, but if you do, I can only argue "Good,
maybe a lot of the garbage already on CPAN can be moved to their
proper place now".
That's a fair point. I will stipulate that if anything, the Author::
namespace is probably nicer than all those that already exist.

Still, the point wasn't "could we move stuff from one point to another", but
"if you're raising the idea of putting even another namespace for even more
things, I'd like to draw your attention to the fact that I think that whole
my-personal-CPAN-inside-CPAN is a bad idea".
Yeah, I understand you POV. I just think you are wrong to think that,
just because it's personal, it doesn't have value to others.
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.

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.
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. :)

I simply gave my (loud) opinion.

Thanks for the time you took to reply to me, appreciated.
No, thank you. :)

Have an awesome day,
s.

Reply via email to