Steve Borho wrote, On 04/16/2009 10:38 PM:
1) In a clean checkout / tarball, the default paths should all just workThat could be by having a very simple paths.py checked in, which declares paths relative to __file__?Having a file that's checked in but intended to be overwritten is troublesome. It'll get committed accidentally often enough that people will curse your name.
This/these paths.py would _only_ be overwritten/patched in distribution packages, never when running from a source tree, so it will be hard to commit accidentially.
The alternative would be that a paths.py or .pyc left in the source directory directory could make a difference without showing up in a diff. And tortoisehg .hgignores .pyc files, so a forgotten paths.pyc will not even show up on a hg status.
For these reasons I think my proposal would cause less cursing than the alternatives.
Having all this logic in one place so it's only done once is a bonus, and symlinks to hgtk and nautilus-thg.py should just work without touching the source code.Shared between hgtk and nautilus-thg? AFAICS they do not share any other code? One of them calls the other, but they don't need to be tightly integrated. I think it is just fine that they are separate tools focusing on being good at different tasks.hgtk and nautilus-thg can both use the tortoise/ module. That's all I intended.
Does that mean that you have changed your mind since http://www.mail-archive.com/[email protected]/msg02976.html ?
AFAICS, right now I agreed with you that the tortoise module is _only_ used by nautilus-thg.py and tortoisehg.py. So sharing this module with hgtk would introduce a new dependency. It seems to me that the tortoise module is focused on support for "file explorer" integration. In my opinion it would be unfortunate to add a dependency from hgtk to that. I would rather introduce a new shared module.
However, my destructive attack do not leave many lines of code that could be shared. And hgtk and the explorer/nautilus plugins have different runtime environments and lifetime and might thus have different requirements and constraints and not so much in common. So right now I don't see much need for a new shared module.
Couldn't we consider this a separate issue and deal with it later? /Mads
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
