easy_install: fragment support
I've attached a patch to detect fragments. There was a couple ideas bandied about; this seems the simplest. You use a link do: url#egg=package You can include a version, otherwise it's unversioned. The only package I've tested it on is "flup", listed on http://pythonpaste.org/package_index.html -- in that case there's no competing or versioned listings in PyPI; if there was the entry would simply be ignored and would be useless. PJE aso mentioned calling the packages things like flup_devel, so that it's a completely different package from flup. The problem, then, is that requirements can't be satisfied by the development package. It seems better to have some magic version string for development, that is neither more or less than other versions (or at least it depends on context -- it's the highest version number when using --develop [should that be implemented], and the lowest otherwise). But that's only useful given a --develop option to easy_install.py. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org Index: setuptools/package_index.py =================================================================== RCS file: /cvsroot/python/python/nondist/sandbox/setuptools/setuptools/package_index.py,v retrieving revision 1.11 diff -r1.11 package_index.py 8a9,10
# make emacs happy: ' EGG_FRAGMENT = re.compile(r'egg=([^=&]*)') 44,45c46,47 < < path = urlparse.urlparse(url)[2]
scheme, server, path, parameters, query, fragment = \ urlparse.urlparse(url)
46a49,53
if fragment: match = EGG_FRAGMENT.search(fragment) if match: return interpret_distro_name( url, match.group(1), metadata)
421a429,432
# Remove any fragments from the URL # url = url.split('#', 1)[0]
At 06:17 PM 7/16/2005 -0500, Ian Bicking wrote:
I've attached a patch to detect fragments.
Would you mind doing it as a unidiff? I'm having trouble understanding/applying it without context. Thanks.
It seems better to have some magic version string for development, that is neither more or less than other versions (or at least it depends on context -- it's the highest version number when using --develop [should that be implemented], and the lowest otherwise). But that's only useful given a --develop option to easy_install.py.
I was actually thinking that such packages should have their Distribution object be of a new 'type', which would have lower precedence than other distribution types unless development mode was in effect (in which case other distribution types would be ignored).
Phillip J. Eby wrote:
At 06:17 PM 7/16/2005 -0500, Ian Bicking wrote:
I've attached a patch to detect fragments.
Would you mind doing it as a unidiff? I'm having trouble understanding/applying it without context. Thanks.
Sure, attached again...
It seems better to have some magic version string for development, that is neither more or less than other versions (or at least it depends on context -- it's the highest version number when using --develop [should that be implemented], and the lowest otherwise). But that's only useful given a --develop option to easy_install.py.
I was actually thinking that such packages should have their Distribution object be of a new 'type', which would have lower precedence than other distribution types unless development mode was in effect (in which case other distribution types would be ignored).
You mean like a Distribution subclass? Would that class just be used anytime there wasn't any version information, or would there be a way of indicating that it was a development version in the filename/fragment? -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org Index: setuptools/package_index.py =================================================================== RCS file: /cvsroot/python/python/nondist/sandbox/setuptools/setuptools/package_index.py,v retrieving revision 1.11 diff -u -r1.11 package_index.py --- setuptools/package_index.py 12 Jul 2005 05:31:36 -0000 1.11 +++ setuptools/package_index.py 17 Jul 2005 02:59:14 -0000 @@ -6,6 +6,8 @@ from distutils.errors import DistutilsError HREF = re.compile(r"""href\s*=\s*['"]?([^'"> ]+)""", re.I) + # make emacs happy: ' +EGG_FRAGMENT = re.compile(r'egg=([^=&]*)') URL_SCHEME = re.compile('([-+.a-z0-9]{2,}):',re.I).match EXTENSIONS = ".tar.gz .tar.bz2 .tar .zip .tgz".split() @@ -41,9 +43,14 @@ def distros_for_url(url, metadata=None): """Yield egg or source distribution objects that might be found at a URL""" - - path = urlparse.urlparse(url)[2] + scheme, server, path, parameters, query, fragment = \ + urlparse.urlparse(url) base = urllib2.unquote(path.split('/')[-1]) + if fragment: + match = EGG_FRAGMENT.search(fragment) + if match: + return interpret_distro_name( + url, match.group(1), metadata) return distros_for_filename(url, base, metadata) @@ -419,6 +426,10 @@ def _download_url(self, scheme, url, tmpdir): + # Remove any fragments from the URL + # + url = url.split('#', 1)[0] + # Determine download filename # name = filter(None,urlparse.urlparse(url)[2].split('/'))
At 10:03 PM 7/16/2005 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
At 06:17 PM 7/16/2005 -0500, Ian Bicking wrote:
I've attached a patch to detect fragments.
Would you mind doing it as a unidiff? I'm having trouble understanding/applying it without context. Thanks.
Sure, attached again...
Thanks; I hope you don't mind if I don't include the "make emacs happy" bit that I don't understand. :)
It seems better to have some magic version string for development, that is neither more or less than other versions (or at least it depends on context -- it's the highest version number when using --develop [should that be implemented], and the lowest otherwise). But that's only useful given a --develop option to easy_install.py.
I was actually thinking that such packages should have their Distribution object be of a new 'type', which would have lower precedence than other distribution types unless development mode was in effect (in which case other distribution types would be ignored).
You mean like a Distribution subclass?
No, I mean a distribution type (the 'distro_type' attribute of Distribution). There are currently type codes for eggs, binary distributions (e.g. win32.exe), and source distributions. The type code is a tie-breaker in sorting, when two distributions have the same version; if more than one suitable package of the highest version is available, EasyInstall chooses to use eggs or binaries in preference to source distributions. Similarly, I was thinking we would select a type code that would cause CVS/Subversion checkouts to have an even lower precedence unless --develop was supplied. I'm also thinking that --develop should take an argument: a parent directory in which the package(s) should be checked out.
On Jul 16, 2005, at 5:37 PM, Phillip J. Eby wrote:
At 10:03 PM 7/16/2005 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
At 06:17 PM 7/16/2005 -0500, Ian Bicking wrote:
I've attached a patch to detect fragments.
Would you mind doing it as a unidiff? I'm having trouble understanding/applying it without context. Thanks.
Sure, attached again...
Thanks; I hope you don't mind if I don't include the "make emacs happy" bit that I don't understand. :)
The "make emacs happy" comment is to fix syntax highlighting. It thinks there is an unclosed single quote string (I guess it doesn't understand r"""strings""" properly). -bob
Phillip J. Eby wrote:
At 10:03 PM 7/16/2005 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
At 06:17 PM 7/16/2005 -0500, Ian Bicking wrote:
I've attached a patch to detect fragments.
Would you mind doing it as a unidiff? I'm having trouble understanding/applying it without context. Thanks.
Sure, attached again...
Thanks; I hope you don't mind if I don't include the "make emacs happy" bit that I don't understand. :)
Like Bob said, it's to fix Emacs syntax highlighting, which doesn't understand triple-quoted strings. package_index.py looks like one giant string in Emacs without it.
I'm also thinking that --develop should take an argument: a parent directory in which the package(s) should be checked out.
That sounds like a good idea; I hadn't thought through exactly how that would work. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org
participants (3)
-
Bob Ippolito -
Ian Bicking -
Phillip J. Eby