At 03:41 AM 2/14/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
On top of PyPI and Cheesecake I've build a Cheesecake service - a service which automatically downloads and scores new package releases. It is available at this address: http://pypi.pycheesecake.org/pypi/ . Probably of most interest here is the easy_installability page (http://pypi.pycheesecake.org/pypi/easy_installability) which shows releases which are listed on PyPI, yet still can't be easy_installed. [snip] I'm open to any suggestions on how this service can be improved.
More information about *how* the installation failed would be useful for package authors to see at a glance what's wrong. Right now, it's too easy to dismiss it as a peculiarity of your installation. Being able to click through and see the log/tracebacks would probably make it more likely that an author spots the problem(s).
Phillip J. Eby wrote:
At 03:41 AM 2/14/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
On top of PyPI and Cheesecake I've build a Cheesecake service - a service which automatically downloads and scores new package releases. It is available at this address: http://pypi.pycheesecake.org/pypi/ . Probably of most interest here is the easy_installability page (http://pypi.pycheesecake.org/pypi/easy_installability) which shows releases which are listed on PyPI, yet still can't be easy_installed. [snip] I'm open to any suggestions on how this service can be improved.
More information about *how* the installation failed would be useful for package authors to see at a glance what's wrong. Right now, it's too easy to dismiss it as a peculiarity of your installation. Being able to click through and see the log/tracebacks would probably make it more likely that an author spots the problem(s).
Looks like it's in there, but two links away, and the installation logs specifically are buried in the rest of the logs. Also the logs are served up as a Python script or something, not text/plain. Ideally the logs would be HTML with anchors, and then you could just add a link on the easy_installability to package_log_uri#installability. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
On 2/14/07, Ian Bicking <ianb@colorstudy.com> wrote:
Phillip J. Eby wrote:
More information about *how* the installation failed would be useful for package authors to see at a glance what's wrong. Right now, it's too easy to dismiss it as a peculiarity of your installation. Being able to click through and see the log/tracebacks would probably make it more likely that an author spots the problem(s).
Looks like it's in there, but two links away, and the installation logs specifically are buried in the rest of the logs. Also the logs are served up as a Python script or something, not text/plain. Ideally the logs would be HTML with anchors, and then you could just add a link on the easy_installability to package_log_uri#installability.
Good idea. I will have to tweak Cheesecake output a bit, but it is certainly possible. I will let the list know when I finish the implementation. Cheers, mk
On 2/14/07, Ian Bicking <ianb@colorstudy.com> wrote:
Looks like it's in there, but two links away, and the installation logs specifically are buried in the rest of the logs. Also the logs are served up as a Python script or something, not text/plain. Ideally the logs would be HTML with anchors, and then you could just add a link on the easy_installability to package_log_uri#installability.
OK, logs are now served as HTML pages. Easy_installability page links directly to certain parts of log files. I have a question concerning some of the failing packages. As an example let's take DisplayShelf 1.0. Cheesecake fails to install it, because in its setup.py it imports "turbogears.finddata", which isn't installed on pybots.org. Log file for DisplayShelf is here: http://pypi.pycheesecake.org/pypi/log/171-DisplayShelf==1.0-success-5.log#in... . Package has defined "TurboGears" in "install_requires", but is using import that will only be working if TurboGears is already there. In fact, whole setup.py is unusable, because it simply fails to run on systems without TurboGears. Where is the problem and how it can be solved? Cheers, mk
Michał Kwiatkowski wrote:
On 2/14/07, Ian Bicking <ianb@colorstudy.com> wrote:
Looks like it's in there, but two links away, and the installation logs specifically are buried in the rest of the logs. Also the logs are served up as a Python script or something, not text/plain. Ideally the logs would be HTML with anchors, and then you could just add a link on the easy_installability to package_log_uri#installability.
OK, logs are now served as HTML pages. Easy_installability page links directly to certain parts of log files.
If you add some blank space to the bottom of the page the anchors can be a little more clear. Like in what you link to, it shows up about halfway down the page because there's not enough below it to fill the space. Another more complex solution is some Javascript that sees the anchor and highlights the anchor based on that. But a bunch of <br>'s is much easier ;)
I have a question concerning some of the failing packages. As an example let's take DisplayShelf 1.0. Cheesecake fails to install it, because in its setup.py it imports "turbogears.finddata", which isn't installed on pybots.org. Log file for DisplayShelf is here: http://pypi.pycheesecake.org/pypi/log/171-DisplayShelf==1.0-success-5.log#in... . Package has defined "TurboGears" in "install_requires", but is using import that will only be working if TurboGears is already there. In fact, whole setup.py is unusable, because it simply fails to run on systems without TurboGears. Where is the problem and how it can be solved?
I think that's just a broken package. It shouldn't do that. Actually finddata probably isn't necessary anymore if they use include_package_data=True. Otherwise they should copy that file into their package before using it. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
At 09:14 PM 2/14/2007 -0600, Ian Bicking wrote:
I think that's just a broken package. It shouldn't do that. Actually finddata probably isn't necessary anymore if they use include_package_data=True. Otherwise they should copy that file into their package before using it.
Well, there's broken and there's broken. Obviously, for most TurboGears users the package isn't going to fail - either they have Turbogears or the egg is going to be downloaded instead of the source tarball, which means that the setup.py won't be an issue. That having been said, what you just said is of course also 100% correct - they should probably be using include_package_data instead. By the way, it's not entirely clear to me what the Cheesecake system actually tests. My initial response to some of the TurboGears packages being listed as not installable was disbelief, because they are in fact usable with easy_install, as long as the author of the package uploaded an egg compatible with your Python version and platform. It's merely the case that building the package from source will fail without TurboGears being present. However, this makes me wonder if there are false successes as well. If Cheesecake merely tests whether "setup.py install" works, this is not the same as easy_install being able to run on the package. For example, Twisted has a working "setup.py install", but it is pretty much impossible to install with easy_install. Twisted isn't listed on the current page, but I wonder what column it would be in, if it were.
On 2/15/07, Ian Bicking <ianb@colorstudy.com> wrote:
Another more complex solution is some Javascript that sees the anchor and highlights the anchor based on that. But a bunch of <br>'s is much easier ;)
OK, done. Tested on Firefox and Konqueror. Cheers, mk
participants (3)
-
Ian Bicking -
Michał Kwiatkowski -
Phillip J. Eby