[sorry for the terrible email quoting / formatting - I'm stuck in webmail ATM.
I'm also having trouble following the discussion PJE and Jim are having - and
that's a concern to me because some of the stuff I'm reading worries me.]
I have created a branch for this and have begun the slow process of working in
the setuptools name mangling. It's going to take some time since package names
are used all over the place and form an integral part of the database
referential structure.
My "plan" for implementation of this is as follows:
1. Convert meta-data supplied by end users using safe_name. We call this "name"
internally (replacing the current use of that column). The original name is
retained for display purposes, stored as "display_name" on the packages table.
2. All user input of names for filtering must be mangled before searching is
performed.
3. Find all places where we display names and convert them to use the
"display_name" column.
Philip wrote:
> Yes, and we should deal with it by rejecting registration of colliding
> names.
Actually, the interface would currently respond saying "You are not allowed to
store '%s' package information" since they'll be trying to manage a package
they don't have permission for.
I guess we could try matching the incoming un-mangled name against the
display_name for the package in question, and use that to generate a nicer
message.
> Meanwhile, if you go to /pypi/SQLObject now, you get back a list of links
> that includes SQLObject2, so there's obviously some kind of mangling taking
> place for URL searches already.
Well, if you call SQL LIKE "name mangling" then I suppose so ;)
I'd consider the above behaviour to be a bug, and will fix it if I remember /
have enough energy to care.
Richard
_______________________________________________
Catalog-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
