easy_install fails on sourceforge?
Hi, I'm struggling with easy_install to download packages from sourceforge. Eg. pyOpenSSL can not be downloaded for windows. even if adding <http://sourceforge.net/project/showfiles.php?group_id=31249&package_id=90289> as find-link. Any hints how I can work around this issue? -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
On Jun 27, 2009, at 11:25 AM, Hartmut Goebel wrote:
Hi,
I'm struggling with easy_install to download packages from sourceforge.
Eg. pyOpenSSL can not be downloaded for windows. even if adding <http://sourceforge.net/project/showfiles.php?group_id=31249&package_id=90289
as find-link.
Any hints how I can work around this issue?
A workaround is looking if pip supports it and start recomending it to your users. I vagaly remembers downloading things from sf links with easy_install, but it was somewhat long ago, maybe sf or setuptools changed since that. []'s -- Leonardo Santagada santagada at gmail.com
At 04:25 PM 6/27/2009 +0200, Hartmut Goebel wrote:
Hi,
I'm struggling with easy_install to download packages from sourceforge.
Eg. pyOpenSSL can not be downloaded for windows. even if adding <http://sourceforge.net/project/showfiles.php?group_id=31249&package_id=90289> as find-link.
Using that as a find-link works fine for me; it downloads the 0.9 source package, since I don't have Python 2.6. (The windows files shown there are all for Python 2.6.)
P.J. Eby schrieb:
Using that as a find-link works fine for me; it downloads the 0.9 source package, since I don't have Python 2.6. (The windows files shown there are all for Python 2.6.)
So my explanation has bee a bit short, I see. This is not what I want. Esp. the source is not found at sourceforge but via pypi :-) Try without using an index. I would expect to get pyOpenSSL-0.8.winxp32-py2.5.exe from SF, but is is not found: easy_install -i file://NUL -f 'http://sourceforge.net/project/showfiles.php?group_id=31249&package_id=90289' pyOpenSSL==0.8 I use the following script for testing. Setting loglevel to 5 would report any link found, but in this case no link is reported (and package is found). ....8<------------- from setuptools.command import easy_install from distutils import log log.set_verbosity(5) # this would print any found link args = """ -i file://NUL -f http://sourceforge.net/project/showfiles.php?group_id=31249&package_id=90289 pyOpenSSL==0.8""".split() easy_install.main(args) ....8<------------- -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
I'm getting a similar issue (easy_install failing on sourceforge) when trying to download Pyro: $ easy_install -eb. Pyro /usr/lib/python2.6/dist-packages/Pyrex/Compiler/Errors.py:17: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 self.message = message Searching for Pyro Reading http://pypi.python.org/simple/Pyro/ Reading http://pyro.sourceforge.net Reading http://sourceforge.net/project/showfiles.php?group_id=18837 No local packages or download links found for a source distribution of Pyro error: Could not find suitable distribution for Requirement.parse('Pyro') The thing is, there is a source distribution of Pyro right there on the SourceForge website. Why doesn't this grab the .tar.gz file and build and install it? I thought setuptools did this automatically. Perhaps my memory is failing me. (It wouldn't be the first time.) -Andrew
At 06:26 PM 6/29/2009 -0700, Andrew Straw wrote:
I'm getting a similar issue (easy_install failing on sourceforge) when trying to download Pyro:
$ easy_install -eb. Pyro /usr/lib/python2.6/dist-packages/Pyrex/Compiler/Errors.py:17: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 self.message = message Searching for Pyro Reading http://pypi.python.org/simple/Pyro/ Reading http://pyro.sourceforge.net Reading http://sourceforge.net/project/showfiles.php?group_id=18837 No local packages or download links found for a source distribution of Pyro error: Could not find suitable distribution for Requirement.parse('Pyro')
The thing is, there is a source distribution of Pyro right there on the SourceForge website. Why doesn't this grab the .tar.gz file and build and install it? I thought setuptools did this automatically. Perhaps my memory is failing me. (It wouldn't be the first time.)
Two things. First, the correct URL for Pyro downloads is http://sourceforge.net/project/showfiles.php?group_id=18837&package_id=29259 . Second, Sourceforge has changed their pages again so that they no longer give direct links to downloadable files; instead, they link to a "downloading.php" which setuptools does not recognize as a downloadable file. I'm not sure when this changed on Sourceforge, but I do hope that SF users will complain long and loud about it.
On Mon, 29 Jun 2009 18:52:01 -0700, P.J. Eby <pje@telecommunity.com> wrote:
The thing is, there is a source distribution of Pyro right there on the SourceForge website. Why doesn't this grab the .tar.gz file and build and install it? I thought setuptools did this automatically. Perhaps my memory is failing me. (It wouldn't be the first time.) Two things. First, the correct URL for Pyro downloads is http://sourceforge.net/project/showfiles.php?group_id=18837&package_id=29259 . Second, Sourceforge has changed their pages again so that they no longer give direct links to downloadable files; instead, they link to a "downloading.php" which setuptools does not recognize as a downloadable file. I'm not sure when this changed on Sourceforge, but I do hope that SF users will complain long and loud about it.
Just throwing out some ideas: Wouldn't it be better for package authors to register their packages in PYPI? They don't have to upload the entire tarball .. but even giving a /direct link/ to this would be sufficient. Would providing pypi plugin that uploads sdist's to SourceForge (or freshmeat, so on) make this process easier for package authors? Maybe then the network effect will make setuptools not rely too much on the unreliable download logic .. as eventually most SF packages would have a download link on PyPI for every subsequent release. -srid
On Mon, 29 Jun 2009 19:19:25 -0700, "Sridhar Ratnakumar"
Just throwing out some ideas:
Wouldn't it be better for package authors to register their packages in PYPI?
It already exists (be it in command line form). See: http://docs.python.org/distutils/uploading.html
They don't have to upload the entire tarball .. but even giving a /direct link/ to this would be sufficient. Would providing pypi plugin that uploads sdist's to SourceForge (or freshmeat, so on) make this process easier for package authors? Maybe then the network effect will make setuptools not rely too much on the unreliable download logic .. as
eventually most SF packages would have a download link on PyPI for every
subsequent release.
imho the distutils core code is quite good. But it is a little unfriendly to those who don't like command lines (like me - because I can't remember them) I've been tossing around doing a GUI interface for building packages and doing the pypi upload. I think a lot can be done to improve the process too. But you too can play a part to imrove things being at ActiveState.. Why don't you have a look at building in the Python Package Manager into ActivePython. After all, ActivePerl has a package manager.. why can't the same thing be available to python users? Regards David
On 6/29/2009 9:33 PM, David Lyon wrote:
On Mon, 29 Jun 2009 19:19:25 -0700, "Sridhar Ratnakumar"
Just throwing out some ideas:
Wouldn't it be better for package authors to register their packages in PYPI?
It already exists (be it in command line form). See:
Yup, I'm aware of this. I was making a general comment that it is better for package authors to register their packages in PyPI in such a way that they have the 'Download URL' set properly to the actual tarball .. instead of the SF download page (eg: see 'Pyro' in pypi). The implication of this is that .. setuptools users need not rely much on unreliable URL parsing methods.
Why don't you have a look at building in the Python Package Manager into ActivePython. After all, ActivePerl has a package manager.. why can't the same thing be available to python users?
I recall Trent mentioned a while ago in this list that we started working on PyPM (Python Package Manager). In fact, last week .. there was a first internal alpha of the tool which at the moment can download and install packages from the internal binary repository which has over 4000 package releases for mac/lin/win. Although, some important packages (eg: scipy, numpy, pyqt, etc..) are not yet in the repository .. and we need to deal with these build/metadata issues before making a public release. -srid
On Tue, 30 Jun 2009 00:25:33 -0700, Sridhar Ratnakumar <SridharR@activestate.com> wrote:
Yup, I'm aware of this. I was making a general comment that it is better for package authors to register their packages in PyPI in such a way that they have the 'Download URL' set properly to the actual tarball .. ...
In fact, last week .. there was a first internal alpha of the tool which at the moment can download and install packages from the internal binary repository which has over 4000 package releases for mac/lin/win.
ok - so on the one hand you are suggesting that people use pypi and then on the other you are suggesting that activestate will have its own package repository....
Although, some important packages (eg: scipy, numpy, pyqt, etc..) are not yet in the repository .. and we need to deal with these build/metadata issues before making a public release.
Aha - sounds good. David
On 6/30/2009 5:25 AM, David Lyon wrote:
ok - so on the one hand you are suggesting that people use pypi and then on the other you are suggesting that activestate will have its own package repository....
ActiveState uses PyPI to get package tarballs in first place. So, for example, if John uploads "Foo 0.1" to PyPI (at least register an entry .. and point the download URL of tarball), then it will become automatically available in the ActiveState repository. Just like how ppm works with CPAN. I am also adding some functionality to z3c.pypimirror with respect to its external download features .. with the intent to submit patches back to the developers. -srid
Hi, Sridhar Ratnakumar schrieb:
Wouldn't it be better for package authors to register their packages in PYPI? They don't have to upload the entire tarball .. but even giving a /direct link/ to this would be sufficient. Would providing pypi plugin
AFAIK this would require the package owner to give all the opload-links. This fails for the common case of prebuild Windows binaries, which are often provided by independent project. Examples are GTK (which in addition provided some different packages) and psycopg2. -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
Hi, P.J. Eby schrieb:
Second, Sourceforge has changed their pages again so that they no longer give direct links to downloadable files; instead, they link to a "downloading.php" which setuptools does not recognize as a downloadable file.
For my usecase I appended this to PackageIndex.process_url(): SF_ONCLICK = re.compile(r"""onClick\s*=\s*"\s*init_download\(\s*'(.*?)'\);\s*\"""", re.I) # handle sourceforge links for match in SF_ONCLICK.finditer(page): link = urlparse.urljoin(base, htmldecode(match.group(1))) self.process_url(link) This checks the onClick attribute. Not nice, but works. -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
participants (6)
-
Andrew Straw -
David Lyon -
Hartmut Goebel -
Leonardo Santagada -
P.J. Eby -
Sridhar Ratnakumar