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.
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
