Without the need for a CPAN client? This requires Module::Install, which doesn't come with Perl. | [reply] |
| [reply]
[d/l] |
D'oh!
I think the naming convention here is entirely unfortunate. That it lines up with, say, Debian's installer, is not a redeeming feature to me. If I were to use an install program, alone, to install Task::Foo, or whatever Debian uses, that's one thing. The install namespace probably doesn't collide with anything else.
However, this namespace also happens to be shared with actual code namespaces. Personally, I'd rather see Bundle:: fixed than see this. Even then, doing anything along these lines seems to just perpetuate the hack of reusing the install/code namespace for purely install purposes.
Why am I so concerned? I already have a whole Task namespace at work, with a Task manager packager, and a base Task package, which all my tasks are derived from, and if I had ever thought about sharing it with CPAN, I wouldn't really want to rename it if possible. So I would have a huge collision in sharing this piece of our infrastructure.
Be careful when introducing new top-level namespaces. Be even more careful when it's not for code. If you need a new namespace, I would have suggested Install or, even better, BundleInstall or something that was more in line with what you're doing. Task isn't it - task is something you do, and it's not a leap of logic to assume that code would do something, and those could be tasks.
You're not just colliding with our code in surprising ways, you're colliding with our ability to use anyone whose bundles follow your convention. Not preventing us from doing so, but definitely making it a bigger headache than if you picked a better namespace.
| [reply] |
No offense, but alias already released this way back in 2005, after extensive namespace discussions on module-authors, and posts of his on use.perl. Of all the propositions made, Task is by far the sanest.
The Bundle namespace will never be fixed of course, since it contains all kinds of ancient magic.
Finally, your argument that it collides with your private Task namespace could easily be reversed: you shouldn't be using such generic namespaces for in-house code ;)
| [reply] |