At 03:03 AM 4/23/2009 +0000, Chad wrote:

I feel that the above is a bug. '.' should be treated as a path not a package name, since '.' is not a valid package name.

Actually, it is.

i haven't looked at the code yet, but it seems that a regular expression should be able to determine between a valid package name, an http address, and a path on disk. it seems like '.' was added as a special case, because other relative paths don't seem to be supported:

$ cd /path/to/mypackage $ easy_install ../mypackage[extraFeature] error: Not a URL, existing file, or requirement spec: '../mypackage[extraFeature] '

As it says in the error message, arguments are checked for a URL, existing file, or a requirement spec -- and in that order. URL-ness is checked by regex. Filename-ness is checked by checking for the existence of the file or directory, not by parsing. If the file doesn't exist, an attempt is made to parse it as a requirement spec. '.[foo]' is neither a URL nor an existing file, but it *is* a valid requirement spec, for a package named '.'. I don't know of any way to change any of this without changing the command-line API. The recommended workaround for building a local package with extras is: easy_install . packagename[extras] as this will first install the local package, then install the specified extras.