On Thu, Apr 16, 2009 at 2:08 PM, Mads Kiilerich <[email protected]> wrote: > Steve Borho wrote, On 04/15/2009 04:57 AM: >> >> The approach I would like to end up with has three tiers: > > I will ask some stupid questions to test how serious you are about the > design you propose. Not because I strongly disagree, but in order to see if > we can improve on it.
No problem. It's usually TK shooting holes in my ideas, so this breaks up the routine a bit :) >> 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. >> 2) For frozen builds, there should be special case code that uses relative >> paths >> > > The freezing is done by a build script. Why can't it overwrite paths.py like > other build scripts should? The build script knows where icons are relative > to hgtk.exe, but it vould be a layering violation if hgtk.py know where the > build script puts the icons. True. As a matter of fact, we do have a group that are building a special frozen environment with their own relative paths. So this makes sense. >> 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. >> I would prefer the paths file to use functions, just in case a packager >> needs to include search logic in there. >> > > The search logic would have to be run on _every_ invocation of the binary > anyway. If it is put in a function then we might have to cache the result > anyway. So why can't the packager just put the search logic in the top level > code of paths.py? (With the frozen-handling being one example of that.) And > I think it is nice that paths.py in the simple case is declarative > configuration in python syntax, so that it can scale to also handle more > complex cases. Yep, that's a good point. ==== So, if I'm adding up the compromises correctly I get: Default code path from checkout/tarball should just work, even when hgtk and/or nautilus-thg.py are symlinked into place. Binary distributions (frozen or not) must supply a paths file. A single module in tortoise/ will read the paths file and provide results to hgtk, nautilus-thg.py, and the shell extensions. The paths file exports simple string variables My primary goal is to make it as simple as possible for a potential TortoiseHg developer to get up and running. Clone, symlink, run. On Windows this is (install a boatload of tools), clone, register, run. -- Steve ------------------------------------------------------------------------------ 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
