Bug#409864: Unspeakable evil is possible even in python
On 9/02/2007, at 10:51 PM, Christian Perrier wrote: Please don't misinterpret my previous comments as criticism of you as maintainer -- whoever wrote the code evidently just completely failed to consider setups different to their own. That is interesting because, being currently subscribed to the package's PTS even though I'm not the maintainer, I actually didn't went through your entire bug report mostly because of the way it was explained at the beginning. I mostly read something like this package is providing brain-dead codewhich then prevented me to hear the very valid arguments you developed further...which I actually read when I read your *second* mail. Something interesting to consider, maybe, when interacting with package maintainers and developers..:-) Yep. I do try to at least remain civilised when ranting. I think the problem may be that I tend to end up missing out writing steps of explanation which I have drafted and redrafted in my head, and jump straight to the conclusion. It *is* brain-dead code, though ;-) Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409864: Unspeakable evil is possible even in python
Please don't misinterpret my previous comments as criticism of you as maintainer -- whoever wrote the code evidently just completely failed to consider setups different to their own. That is interesting because, being currently subscribed to the package's PTS even though I'm not the maintainer, I actually didn't went through your entire bug report mostly because of the way it was explained at the beginning. I mostly read something like this package is providing brain-dead codewhich then prevented me to hear the very valid arguments you developed further...which I actually read when I read your *second* mail. Something interesting to consider, maybe, when interacting with package maintainers and developers..:-) signature.asc Description: Digital signature
Bug#409864: Unspeakable evil is possible even in python
OK, well take a look at line 761 in viewvc.py and it being called from line 827, and laugh. Consider for a moment the explicitly-set relative template paths in the viewvc.conf that has been generated for you. Consider further the absolute futility of setting the template_dir option. Then switch to cvsweb or something. A fine example of shit code in any language. For a workaround, either set the template_dir option in the [options] section of your viewvc.conf and comment out all of the explicit templates specified in the [templates] section, or just make sure that every template in the [templates] section is specified with an absolute path. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409864: Unspeakable evil is possible even in python
El viernes, 9 de febrero de 2007 00:40, Nick Phillips escribió: OK, well take a look at line 761 in viewvc.py and it being called from line 827, and laugh. Consider for a moment the explicitly-set relative template paths in the viewvc.conf that has been generated for you. Consider further the absolute futility of setting the template_dir option. Only if it is relative, not absolute. There is a: if os.path.isabs(path): that should take care of giving back the path unaltered if it is absolute, which is our case. Then switch to cvsweb or something. A fine example of shit code in any language. For a workaround, either set the template_dir option in the [options] section of your viewvc.conf and comment out all of the explicit templates specified in the [templates] section, or just make sure that every template in the [templates] section is specified with an absolute path. Maybe I am completely slept or something, but the viewvc.conf from Rodrigo only has the default configuration, that is, an absolute template_dir parameter and no explicit template. I do not see your point, sorry. Heading my bed. Best regards, Ender. -- Network engineer Debian Developer pgpgMBfOtr6yp.pgp Description: PGP signature
Bug#409864: Unspeakable evil is possible even in python
On 9/02/2007, at 3:04 PM, David Martínez Moreno wrote: El viernes, 9 de febrero de 2007 00:40, Nick Phillips escribió: OK, well take a look at line 761 in viewvc.py and it being called from line 827, and laugh. Consider for a moment the explicitly-set relative template paths in the viewvc.conf that has been generated for you. Consider further the absolute futility of setting the template_dir option. Only if it is relative, not absolute. There is a: if os.path.isabs(path): that should take care of giving back the path unaltered if it is absolute, which is our case. Not if the individual template settings are relative, which in my migrated config (from a standard viewcvs config), they are. i.e. template_dir is set and absolute, individual template names are set and relative, and the result is breakage. Maybe I am completely slept or something, but the viewvc.conf from Rodrigo only has the default configuration, that is, an absolute template_dir parameter and no explicit template. I do not see your point, sorry. I'm guessing I'm not the only one who is using this as a migration from viewcvs. In any case, irrespective of the config file that we may or may not ship/create, the behaviour that viewvc exhibits when a relative template name is set is nuts. I would suggest that: * If absolute template paths are explicitly set per-template, they are used * If relative templates (which include the defaults) are to be used, then they should be relative to the specified template_dir * If relative templates are to be used, and template_dir is not set, then they should be relative to /etc/viewvc -- not the result of some half-baked attempt to find some kind of installation dir. Note that _install_path appears also to be used e.g. to determine where to tell cvsgraph to look for config files. Which is also crazy and broken. Please don't misinterpret my previous comments as criticism of you as maintainer -- whoever wrote the code evidently just completely failed to consider setups different to their own. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago
Bug#409864: Unspeakable evil is possible even in python
On 9/02/2007, at 3:04 PM, David Martínez Moreno wrote: Maybe I am completely slept or something, but the viewvc.conf from Rodrigo only has the default configuration, that is, an absolute template_dir parameter and no explicit template. I do not see your point, sorry. Sorry, hadn't looked at his conf file -- I'd just found this bug when about to report one myself, and thought it looked like the same one. Since the behaviour I thought I was describing (relative names in templates section, absolute template_dir set, result broken because for some reason it is using /usr/lib as a prefix) is clearly a problem, I suggest that fixing it to use template_dir as a prefix whenever the per-template name is relative (i.e. is using the default or is specified as a relative name in the config) would be a good idea, and might well fix his problem as well as mine. Oh, and the default for template_dir obviously needs to be sensible too, rather than calculated from __file__! Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago
