On Thu, Apr 16, 2009 at 4:31 PM, Mads Kiilerich <[email protected]> wrote: > Steve Borho wrote, On 04/16/2009 10:38 PM: >>>> >>>> 1) In a clean checkout / tarball, the default paths should all just work >>>> >>>> >>> >>> That 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.
AFAIK distutils operates by packaging up what is in your working directory. ie: you generate files and then tar them up. So anyone who is generating packages would have a broken path file. My distutils knowledge is pretty shallow, so if someone shows me how this can be done without mangling the working copy, I would be ok with it. > 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. Ugh. That's asking for troubles. > For these reasons I think my proposal would cause less cursing than the > alternatives. BTW: The symlink requirement does require special code in both hgtk and nautilus-thg.py to insert a path into sys.path. I doubt there's any way around that. >>>> 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 > ? I was stating the facts as they were, not laying down the law. > 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. This could be a place we duplicate data just for simplicity. The typical solution for this is to give the information to the shell, which then communicates the data to hgtk via the environment. But hgtk also needs to be able to operate outside of the shell as a standalone tool. > Couldn't we consider this a separate issue and deal with it later? Moving to C++ shell extensions is going to have large implications on the repository layout. We should probably address that first. I've never particularly liked the name tortoise for that package, as it could potentially collide with other python tortoise implementations in site-packages (perhaps tortoisebzr). Simon H has already split out the menu and cache implementations into separate modules so they could be shared with nautilus, so we should probably move that code into a package named thgshell or something similar. I assume the win32 specific files in tortoise/, tortoise/tests, and the tortoisehg.py file will be removed and replaced with this new standalone Python app that uses thgshell and communicates with the C++ shim. Unless someone speaks up that they have this part in hand, I'll have to pick it up in a week or two and at least get a prototype working that others can finish up. Back to the original topic. Perhaps now would be a good time to create a thglib package that has the wrapper functionality of hggtk/hglib.py and these install paths. If we do start a Qt port of our dialogs, we're going to want to share the abstraction code that is in hglib.py. While we're breaking the world, maybe now would be a good time to rename hggtk to hgtk, and hggtk/hgtk.py to hgtk/__init__.py? Hmm, we can't have the hgtk script and a package named hgtk in the same directory, though. -- Steve Borho ------------------------------------------------------------------------------ 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
