Re: [patch] enhancements to package-ui.el

Darryl> Darryl> Darryl> Could you please separate the code that grabs the new Darryl> package-get-base.el into a separate function (in package-admin.el or Darryl> package-get.el -- and not package-ui.el)? Reasons: Darryl> Darryl> * Sometimes you just want to update package-get-base.el. Darryl> Darryl> * People who access these functions via menu picks cannot specify a Darryl> prefix (there's no way to specify a prefix using menu picks). We'll Darryl> probably have to provide a separate (?) menu pick that updates Darryl> package-get-base.el, and maybe yet-another-menu-pick (ugh) that Darryl> updates package-get-base.el before entering the visual package Darryl> installer. All this package-get-base.el stuff is such a pain. Now there's the incremental updates to deal with... blech. I wish we could just reliably and automagically snarf the current one off ftp.xemacs.org. Suggestions anyone? Darryl> Darryl> Dunno. I can think of reasons to do it, and reasons to not do it. Darryl> [...] Darryl> Darryl> This feature needs to be added, but your implementation has Darryl> potential problems: Darryl> Darryl> * The package install directory information needs to be managed by Darryl> package-admin.el. It's best if all the directory information is Darryl> maintained by one module. Darryl> Darryl> * Do we really want to allow installations into arbitrary directories Darryl> (that is, ones which will NOT be located by XEmacs' automatic package Darryl> path finder)? This is an issue for novice users. Personally, I think Darryl> we should restrict package installations to specific "system" Darryl> locations (e.g., to the package-paths specified at configure time) or Darryl> to the user-local location ("~/.xemacs/packages"???). Creating a good Darryl> user-interface for this is a pain, though, and so we might want to Darryl> just settle for some kind of warning if the user enters a "bad" path. I would definitely like to be able to specify anywhere, though I'd settle for a command which requires a prefix argument to allow that. OK, how about if I create 2 variables: package-get-default-install-dir and package-get-default-conflict which serve as the values of those arguments to package-get when unspecified (ie, nil). Then I add 2 pui commands to set them. How's that sound? (the CONFLICT argument sets the behavior when a package version already exists - should we re-install or ignore) Darryl> Darryl> This sounds like a bug. Newer versions should never be overwritten Darryl> with an older one (well, maybe we should provide yet another prefix Darryl> arg/variable that forces an installation for advanced users). OK, I'll make it a warning if the version passed to package-get is nil (and do no update). Otherwise if a specific version is requested, it'll really get it. This is like a 2 line patch. greg