Ok, here's a better bundle, with tests and all. Which lets you quote some arguments for aliased commands. In order to get it tested, I had to add an optional parameter to the get_alias function in commands.py , which is hopefully not a problem. I also renamed test_command.py to test_commands.py which is the correct name as far as I can tel. I did ask about it on this mailing list, but didn't get any responses, so I just did it. ("Its easier to say sorry, than ask permission." -- Gerard van Harmelen) regards marius <div>On 11/27/06, Aaron Bentley <<a href="mailto:aaron.bentley@utoronto.ca"> aaron.bentley@utoronto.ca</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marius Kruger wrote: > My conclusion was thus that every time config.GlobalConfig () > is called, that the config is read anew. I would like us to > store a instance of the GlobalConfig config somewhere, > and just load it (lazily) and use the same instance everywhere, > so that we don't parse the file a million times. I don't think we do parse the file a million times, though.  Certainly, if we did, that sort of thing would show up on benchmarks. </blockquote><div> :) ok, ok, I don't know how often values will get read from the global config, but it looks to me that the file will be parsed every time. I just went ahead and found another way of solving my problem, but I still think it might be a good idea to cache the config. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> I was thinking something like : > (in bzrlib/config.py) > > _global_config=None > > def get_global_config(): >     if _global_config is not None: >         _global_config = config.GlobalConfig() >     return _global_config When converting a file-backed value into a memory-cached value, you must be careful not to change its behavior.  You would need to test that when bzr sets a value in the global config: 1. that value is written to disk 2. that value is immediately available to bzr</blockquote><div>I'm not saying store it in some other format, just that we should re-use the already created and used config-reading object...  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> It's also worth considering whether we want the in-memory values to change when the file is updated externally.  The semantic thus far is that they would.  The config directory thus far doesn't support any locking, so we can't use that as a hint. Also, if you're considering lazy-loading bazaar.conf, the same mechanism ought to be used for locations.conf, which is usually queried before bazaar.conf.  This suggests that caching the GlobalConfig object is too high-level; LocationConfig has a parameterized constructor, so it can't be cached effectively.  Instead, it might be preferable to cache the ConfigObj returned by IniBasedConfig._get_parser >     > I also think it should be possible to set branch specific aliases, >     > where the branch specific one over-rides the global one. >     > I'll look into supporting this, If thats ok. > >     This seems error-prone and confusing to me, how do you intend to use it? > > > Like you can set branch specific user-email (whoami), > I can imagine that you might want to do interesting aliases which > might only be appropriate for a specific  branch, > for example you might want a  particular branch to > output its diff differently, with some funny diff options or something.. This doesn't sound convincing to me.  My experience with similar systems is that they aren't very helpful, because it's easy to forget precisely which behaviors are enabled for which locations.  So you tend to specify things that may-or-may-not be enabled for the current location, anyhow. It's even problematic for the location values like 'pull/merge location', 'push location', 'bound location' and 'submit location', which is why the dev version of bzrtools includes a 'show-paths' command (by Alexander Belchenko) to remind you. ConfigObj supports nesting, so per-location aliases are certainly possible, but I don't think they're useful.</blockquote><div> ok, lets leave it for now, once I  have a use case, I might consider revisiting this. </div> </div> -- coding in python is better than a holiday!