From: Trans Date: 2007-07-12T02:56:10+09:00 Subject: package names (Was: god 0.1.0 released) Let's try this again (I already replied to this once but lost it in the aether somehow...) On Jul 10, 11:24 am, "pat eyler" wrote: > The Ruby community has long held that names are important for methods > -- they should be descriptive and help the programmer. We've never done > a very good job with names for projects/libraries (at least in my opinion), > maybe it's time for us all to spend a little more time and effort in that > direction. Are you suggesting that we should start moving in the Java direction with regards to library naming? Perhaps your are right. Perhaps that someone has now named a library "God" is a real omen. It's a tuffy though. Creative names have been a hallmark of Ruby, with _why being sort of the exemplar. I suspect, to move in the other direction would require a real campaign on the part of the community, especially Matz, the RubyGems teams, and the RubyForge guys. The topic interests me a good bit because I have broken Facets down into a bunch of little mini-projects. Any of which could easily be packaged and distributed independently -- and I have flirted with doing so. But it's problematic for a couple of reasons. Firstly, there's nearly 100 of these mini-projects, and most have fairly generic names. (I don't want to get too creative, or I won't be able to find anything!) So If I released them as such I'd quickly soak a bunch of Gem namespace. But maybe that doesn't matter? OTOH, if I release in a more Java-fashion, say for example, 'facets-annotations' instead of just 'annotations', then I feel like I'm hurting myself from a marketing stand point. Someone else could just come along and use the plain name for themself. So I don't feel like there's much of an option. RubyGems is sort of pushing the use of creative names b/c of this. That's why I've sometimes wished Gems has a project flag. If two packages had the same name than you could select from them based on their project. After all, that's how RubyForge is organized. Secondly, (and maybe this a little OT but...) if I did release these many mini-projects, I'd run into the issue of potential version conflicts between them and the original all-in-one package, because they contain the same libs. I'm not sure there's an easy way to circumvent this issue should it arise. OTOH, If I instead made the all- in-one project simply a multi-package, i.e. a package that has no libs itself, just dependencies on the many mini-packages, then there's the fact that RubyGems' require implementation is terribly inefficient. Plus Gem's standard install procedure asks you to confirm every dependency. Who wants to do that for 100 mini-libs? Blech! (Yes, I know about -y, but no one expects they'd _have_ to use that for their own sanity ;) T.