classification
Title: IDLE cannot find windows chm file
Type: Stage: resolved
Components: IDLE Versions: Python 3.0, Python 3.1, Python 2.7, Python 2.6
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: kbk Nosy List: benjamin.peterson, gpolo, kbk, loewis, rhettinger, terry.reedy
Priority: release blocker Keywords: 26backport, patch

Created on 2009-04-17 19:11 by rhettinger, last changed 2009-04-26 02:14 by kbk. This issue is now closed.

Files
File name Uploaded Description Edit
issue_5783.diff gpolo, 2009-04-20 22:48
Messages (25)
msg86082 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2009-04-17 19:11
The Doc/Python262.chm file needs to be named Doc/Python26.chm so that
IDLE can find it.  The current release cannot find the chm file at all
so it falls back to the on-line docs at http://www.python.org/doc/current .
msg86083 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2009-04-17 19:13
This also applies to Python31a2.chm --> Python31.chm
msg86084 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-04-17 19:37
It's actually vice versa - IDLE should open the file under its correct name.
msg86086 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2009-04-17 20:09
What changed here?  ISTM that IDLE was always looking for the same name
and that the new part is that the build procedure has been been changed
(the step where the "make htmlhelp" output file is moved to ./Doc and
renamed).
msg86097 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2009-04-17 23:30
It looks like IDLE has been the same since 2004:
 
http://svn.python.org/view/python/trunk/Lib/idlelib/EditorWindow.py?view=diff&r1=36600&r2=36601

The "correct" filename is what has changed.  

The release process needs to have a step that validates that the CHM
file works from IDLE.

FWIW, I think the version naming convention is unnecessary and makes the
IDLE linkage too fragile.  It would be better to just always call the
file Python.chm.  By way of comparison, the regular html docs do not get
custom names -- they are just index.html in a doc directory.
msg86098 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2009-04-17 23:37
Just checked Python2.5.4 and its CHM file is Python25.chm.  So
everything is fine with that release.
msg86100 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-04-17 23:50
> What changed here?

We switched to sphinx, and the makefiles put the full version into the
output files.

> ISTM that IDLE was always looking for the same name
> and that the new part is that the build procedure has been been changed
> (the step where the "make htmlhelp" output file is moved to ./Doc and
> renamed).

No, the "make htmlhelp" output is already called python262.chm. So no
renaming occurs.
msg86102 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-04-18 00:01
> The release process needs to have a step that validates that the CHM
> file works from IDLE.

I personally can't perform such testing steps, perhaps unless somebody
maintains a list of such steps for me.

Instead, I think such problems must be detected during beta testing.
The fact that it hasn't been detected so far, even though it existed
since 2.6.0, indicates that the problem can't be that serious.

> FWIW, I think the version naming convention is unnecessary and makes the
> IDLE linkage too fragile.  It would be better to just always call the
> file Python.chm.  By way of comparison, the regular html docs do not get
> custom names

That's not true: they are called e.g.

python-2.6.2-docs-html.tar.bz2
(see http://docs.python.org/download.html)

I believe that the rationale for calling the CHM file that way is the
same as for putting a version number into any other output.

FWIW, the renaming had caused some troubles in the past, but most of
it is over. Renaming it back will cause more troubles for sure.
msg86103 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-04-18 00:01
> Just checked Python2.5.4 and its CHM file is Python25.chm.  So
> everything is fine with that release.

True. The renaming happened with the switch to sphinx.
msg86207 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2009-04-20 21:52
I think idle should be updated to look for the correct file name.
msg86209 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2009-04-20 22:01
Maybe the functions in Doc/tools/sphinxext/patchlevel.py should be moved
to somewhere else then ? IDLE could use them.
msg86210 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-04-20 22:21
> Maybe the functions in Doc/tools/sphinxext/patchlevel.py should be moved
> to somewhere else then ? IDLE could use them.

No. IDLE shouldn't parse the version out of the header file, but instead
use sys.version_info to compute the file name, so it's really just
get_sys_version_info, and you only need half of its return value.
Copying it is fine, IMO.
msg86211 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2009-04-20 22:48
Fine, Martin. Patch attached for idle only.
msg86217 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2009-04-21 02:18
Fragile solution, but it works.  IMO, it's a better design to just have
the file named Python26.chm like it always used to be done.   Now, we've
duplicated someones arbitrary logic (ignoring sys.version_info.serial
and special casing sys.version_info.release_level=="final") but the
duplication isn't exact because the original puts dots better the major,
minor, and micro versions.  This is asking for another bug someday when
the logic gets changed in one place but not the other.
msg86219 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-04-21 02:48
> Fragile solution, but it works.  IMO, it's a better design to just have
> the file named Python26.chm like it always used to be done.

That was also fragile, as this bug report demonstrates. It broke when
sphinx decided to put more version information into the file names.

So when the file naming algorithm changes in one place and not the
others, it *will* break, no matter what the old algorithm was. The
lesson to be learned is that you just should be *very* careful to ever
change file names. Applying that lesson to the status quo means that
IDLE has to change, not the file name of the CHM file.
msg86349 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2009-04-23 02:45
r71812 in trunk. Will port to 3-head 30-maint 26-maint.
Thanks for the patch!
msg86415 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2009-04-24 16:51
"Instead, I think such problems must be detected during beta testing.
The fact that it hasn't been detected so far, even though it existed
since 2.6.0, indicates that the problem can't be that serious."

I believe I tried F1 Help once, got the online docs, found that
annoying, but did not report because I did not know it was a bug.  I
usually keep .chm open anyway when writing code.  Being able to open
from IDLE would be nicer than via Start / All Programs / Python 3 / docs.

With 3.0.1, I just tried again, but got
"Not Found

The requested URL /dev/3.0/ was not found on this server.
Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_ssl/2.2.9 OpenSSL/0.9.8g
mod_wsgi/2.3 Python/2.5.2 Server at docs.python.org Port 80"

so going online is really broken.
msg86423 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-04-24 18:45
Terry, I believe your issue (online docs not found in 3.0) is different
from this issue, so please open a new issue.

I'm leaving this open until the patches have been forward-ported.
msg86429 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2009-04-24 20:33
My point, relative to this issue, was to explain why I had not commented
before, but also to report that forward porting is needed, and not just
a convenience.  I just reported the breakage to webmaster@python.org.
msg86443 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2009-04-25 03:07
The issue that Terry Reedy raised is due to 68801 being forward
ported to py3k but not backported to 2.6-maint or 3.0-maint.
Access in 2.6.2 happens to work because there's a redirect on
the website which points to the correct doc release.  But 3.0.1
is broken.  I will fix both of those when I port.

Perhaps the reason the chm issue hasn't been more widely reported is that
the chm docs are available from the Python selection in the Start
menu on both releases.

This isn't a problem for the Python webmaster.  We don't want
them starting to change the links underneath us!

I used 'pending' in the Debian sense of: "I'm working it, 
expect an upload soon."  Unless I'm mistaken, there's no bot
closing 'pending' like  there was on SF.  How do the devs
generally use the 'pending' tag?
msg86445 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-04-25 05:47
> I used 'pending' in the Debian sense of: "I'm working it, 
> expect an upload soon."  Unless I'm mistaken, there's no bot
> closing 'pending' like  there was on SF. 

Actually, the Pending status is exactly the one as there was
on SF. The bot closing it just hasn't been installed yet.
msg86532 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2009-04-25 18:00
OK, thanks, Martin.  I'll use 'pending' that way (close after a 
while if the bot hears nothing further).

Changing component to "IDLE'.
release26-maint: r71908, r71909
msg86534 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2009-04-25 18:14
Kurt, I'm not sure if you misunderstood Martin but there is no such
"closing bot" here (only if you consider people as bots :)

Anyway, are you porting these to py3k and release30-maint or can someone
else do it ?
msg86577 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-04-26 00:34
> Kurt, I'm not sure if you misunderstood Martin but there is no such
> "closing bot" here (only if you consider people as bots :)

There is no such bot *yet*, but may be in a few days.
msg86590 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2009-04-26 02:14
I understood Martin completely.  The bot is coming RSN.  My use
of 'pending' was intended to answer the exact question you just
asked.  Maybe I should use Stage: 'commit review'.

Forwardport to py3k: r71952
Backport to 30-maint: r71953
History
Date User Action Args
2009-04-26 02:14:18kbksetstatus: open -> closed

stage: resolved
messages: + msg86590
versions: + Python 2.7
2009-04-26 00:34:52loewissetmessages: + msg86577
2009-04-25 18:14:24gpolosetmessages: + msg86534
2009-04-25 18:01:26kbksetkeywords: + 26backport
nosy: loewis, rhettinger, terry.reedy, kbk, benjamin.peterson, gpolo
components: + IDLE, - Build
2009-04-25 18:00:07kbksetmessages: + msg86532
2009-04-25 05:48:15loewissetmessages: + msg86445
2009-04-25 03:07:44kbksetmessages: + msg86443
2009-04-24 20:33:50terry.reedysetmessages: + msg86429
2009-04-24 18:45:37loewissetmessages: + msg86423
2009-04-24 16:51:05terry.reedysetstatus: pending -> open
nosy: + terry.reedy
messages: + msg86415

2009-04-23 02:45:53kbksetstatus: open -> pending
resolution: accepted
messages: + msg86349
2009-04-21 02:48:13loewissetmessages: + msg86219
2009-04-21 02:18:30rhettingersetmessages: + msg86217
2009-04-21 01:33:01kbksetassignee: kbk

nosy: + kbk
2009-04-20 22:48:30gpolosetfiles: + issue_5783.diff
keywords: + patch
messages: + msg86211
2009-04-20 22:21:38loewissetmessages: + msg86210
2009-04-20 22:01:43gpolosetnosy: + gpolo
messages: + msg86209
2009-04-20 21:52:45benjamin.petersonsetassignee: benjamin.peterson -> (no value)
messages: + msg86207
2009-04-18 00:01:49loewissetmessages: + msg86103
2009-04-18 00:01:19loewissetmessages: + msg86102
2009-04-17 23:50:32loewissetmessages: + msg86100
2009-04-17 23:37:36rhettingersetmessages: + msg86098
2009-04-17 23:30:59rhettingersetpriority: critical -> release blocker

messages: + msg86097
versions: + Python 3.0
2009-04-17 20:09:41rhettingersetmessages: + msg86086
2009-04-17 19:37:53loewissetnosy: + loewis
messages: + msg86084
2009-04-17 19:13:15rhettingersetmessages: + msg86083
versions: + Python 3.1
2009-04-17 19:11:54rhettingercreate