On Sun, Oct 11, 2009 at 3:23 PM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: > > On Oct 11, 12:46 am, Russell Keith-Magee <freakboy3...@gmail.com> > wrote: >> If I may ask - which apps (or app names) caused the collision? Off the >> top of my head, I can't think of any especially mainstream application > > Considering just "mainstream" applications would appear to discount > any applications which are developed in-house and not available to the > wider public. In development shops with numerous development teams, > this could happen and lead to clashes with apps from other teams as > well as when incorporating "mainstream" applications. In such cases > people would just fork, working round the limitation, rather than make > a fuss about it.
This is true, but again, the distinction between theoretical and practical problem emerges. The set of mainstream apps in the wild is much larger than the set of in house apps controlled by any company/group - so if the problem doesn't exist in practice for apps in the wild, the potential for the same problem to emerge in the smaller subset of in-house apps isn't that large. On top of that, companies have the ability to rename their in house resources; they don't have the ability to force apps in the wild to change their name. >> that share a package name. In my experience, the fact that having a >> unique name makes it easier to get Google juice has been enough to >> keep the namespace clean. > > It's the last part of the package name that clashes, as that's used as > the app label, db prefix etc., and I don't see how you'd expect to get > any Google juice from the last part of the name which is typically a > rather prosaic word. I would have thought the Google juice came from > the whole name e.g. "django-registration" or "django-tagging". I was referring to the fact that if your name is unique, it's easy for people to find it. Google isn't good at disambiguating, so it's in the interests of every project owner to choose a name that is unique. Case in point - try looking for web page about Sphinx. You will find, in no particular order: * The Python documentation engine * The full text index server * Information on Greek/Egyptian mythology. On the other hand, it's easy to find details on django-mingus. As a project maintainer, it's in your interest to choose a unique name, and this enlightened self interest has been sufficient to ensure a namespace that has been conflict free in my experience. > So, if my hypothetical site had the concept of tagging in a sense > other than tag clouds (for example, livestock tagging) and I was using > an app whose package name ended in 'tagging', and if I later wanted to > use "django-tagging" in the UI, I'd have to edit one of the 'tagging's > to change the last part of the package name. This particular example > is not a real-world one, and obviously if I'd known that I was going > to use "django-tagging" at the outset and I was writing the other app > I could have named it to end with "tags". But like isn't always like > that :-( So we're talking about a hypothetical situation with two applications named tagging, which *both* need to be used in a single project, where *neither* application can have their name changed (either because they are both in the wild, and the self interest or because in-house policies won't allow a rename). Again - I don't deny that there is a problem in theory. I'm just not convinced that it is a problem in practice. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
