On 9/22/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > > On Sat, 2007-09-22 at 11:52 +0800, Russell Keith-Magee wrote: > > Adding user-space commands is something that only a subset of > > applications will need to do. As a result, there is even less > > potential for clashes here than there is in application space. > > Complicating the basic interface for the invocation of commands to > > account for clashes that aren't likely seems like overkill to me. > > I don't follow this logic. If even one app provides several commands, > the potential for conflict between it and another app's commands exists.
My point is that while the _potential_ for conflict exists, the likelyhood of _actual_ conflict is quite small. The potential for conflict currently exists with the naming of applications. However, for all the potential, it just isn't a problem that we encounter frequently. We don't have any apparatus to check for name clashes, yet it doesn't take too long to determine the source of the problem when it occurs. The solution for this problem isn't to change the way we reference applications for the 99% case - it's to find a way to accomodate the 1% case. In the case of applications, one proposed solution has been to provide an mechanism for installing an app under an alias. Yes, there _could_ be a clash of commands, and a user application _could_ override a default Django command. However, I put it to you that this is the 1% case, not the 99% case. Most applications won't be registering commands, so there isn't a huge probability that a clash will occur - even less of a probability than with applications. Only a malicious application would try to register a command called 'syncdb', and I think the Django community is savvy enough to spot those applications and avoid them. So my question becomes 'how do we accomodate the 1% case'. I would suggest the best approach here would be to check for name clashes when a new command is registered. If a clash is identified, we can either: 1) Raise an error, stopping manage.py 2) Raise a warning, and a) adopt the new command b) ignore the new command 3) Register the duplicate command with an auto-aliased name - the appname.command syntax you proposed is probably a good option here. Any of these options could be easily accommodated with a slight change to line 85-86 of management/__init__.py. Preferences? 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
