From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rusi Newsgroups: gmane.emacs.help Subject: Recursion problems with package management Date: Fri, 14 Aug 2015 19:30:15 -0700 (PDT) Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1439606129 1359 80.91.229.3 (15 Aug 2015 02:35:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Aug 2015 02:35:29 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Aug 15 04:35:26 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZQRJY-0006gB-50 for geh-help-gnu-emacs@m.gmane.org; Sat, 15 Aug 2015 04:35:20 +0200 Original-Received: from localhost ([::1]:48892 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZQRJX-0001gj-DJ for geh-help-gnu-emacs@m.gmane.org; Fri, 14 Aug 2015 22:35:19 -0400 X-Received: by 10.66.146.227 with SMTP id tf3mr43918366pab.21.1439605815886; Fri, 14 Aug 2015 19:30:15 -0700 (PDT) X-Received: by 10.50.25.199 with SMTP id e7mr103893igg.16.1439605815837; Fri, 14 Aug 2015 19:30:15 -0700 (PDT) Original-Path: usenet.stanford.edu!news.glorb.com!Gin.tags.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!se8no4025027igc.0!news-out.google.com!o13ni15833igw.0!nntp.google.com!x6no504879igd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=117.195.40.43; posting-account=mBpa7woAAAAGLEWUUKpmbxm-Quu5D8ui Original-NNTP-Posting-Host: 117.195.40.43 User-Agent: G2/1.0 Injection-Date: Sat, 15 Aug 2015 02:30:15 +0000 Original-Lines: 126 Original-Xref: usenet.stanford.edu gnu.emacs.help:214320 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:106604 Archived-At: Collecting some thoughts and threads on package management here. tl;dr at bottom On Friday, August 14, 2015 at 2:01:08 AM UTC+5:30, Stefan Monnier wrote: > On Thursday, August 13, 2015 at 12:55:26 PM UTC+5:30, Tom=E1s wrote: > > FWIW, and based on a recent experience of mine, yes, I think both ways > > are needed/useful and complement each other. Recently, I installed some > > package from ELPA (magit) and it failed to byte-compile. I've yet to > > investigate what went wrong (perhaps my Emacs version is too new/old, > > what have you), but I now find myself wrangling with the complexities > > of the package itself *and* those of the packaging system. > >=20 > > So some "wholly integrated solution" makes life easier only when things > > work out (duh ;-) Otherwise it makes life harder, and what's more impor= tant > > in my view -- it tends to make a stronger separation of "outer circle" > > and "inner circle", making it more difficult to get involved. > My crystal ball tells me that you upgraded Magit from an Emacs where the > previous Magit was already loaded, and the old (loaded) version > interfered while byte-compiling the new version. > [ The typical interference, looks like this: Emacs tries to compile > foo-1.el which does (require 'foo-2) to get some macros, but (the old) > `foo-2' is already loaded so we end up using the old version of the > macros (or the macros may simply not be defined at all). ] Here that we are at the root of the problem I think -- emacs package-managi= ng=20 emacs is a recursion problem. In short, if emacs package-manager is weak enough it will work... at the cost of being 1/2-assed. If it is full-featured enough to be a basic, all-round useful building block, recursion/meta-circularity needs to be a (significant) factor in its design. Obvious instance of the above: Imagine async.el is a package. How to install async asyncly without async? Here are some random (non emacs) instances of the above issue 1. apt-get upgrade apt-get works What about 'apt-get install apt-get'=20 2. Linux needs a shell, including to startup So there is dash in addition to bash 3. Everything runs on top (transitively) the kernel. But the kernel is a package that can be upgraded. kernel install requires restart. Which needs help of apt/grub etc. 4. The general idea, need, issues for bootloading-OS, bootstrapping-compile= r 5. firefox plugin-install requires restart firefox. Why? Coming to emacs package management Edward's req-package usage-pattern has exemplified use thus [see https://github.com/edvorg/emacs-configs ] There is an init.el containing (add-hook 'after-init-hook (lambda () (load "~/.emacs.d/init-real.el"))) And the real stuff is in init-real.el. Related to the formidable list shown by Robert Thorpe [thread "How can I change the default loading buffer"] On Sunday, August 2, 2015 at 9:26:13 PM UTC+5:30, Robert Thorpe wrote: > Emanuel Berg writes: > > OK, so what is the method to find out (or rule of > > thumb) what you shouldn't put directly into .emacs but > > instead into `emacs-startup-hook'? >=20 > Have a look at (info "(elisp)Startup Summary") and see if any of it > applies to you. Check from the bottom of the list up. >=20 > You can only delay things as far at step 24, so there's little > use in worrying much about the earlier steps. For people who use the > session manager and --daemon they could cause problems though. >=20 > This is how it is for me, going backwards, last step first: >=20 > * 24. `emacs-startup-hook' and `term-setup-hook' are run. > * 23. initial-buffer-choice. Because the initial-buffer-choice is set > here, what happens in emacs-startup-hook can change it. What happens in > the init file can't though. I use this feature. I setup > initial-buffer-choice to my ToDo file. In emacs-startup-hook I look for > a bookmark into my init file, if it exists then I jump to it. > * 22. Exit point for --batch. If you use Emacs a lot in batch mode > it's worth doing a lot of visual stuff in emacs-startup-hook because > that way it won't slow down your batch programs. > * 21. Other command line options. I think this includes files > specified on the command line. > * 20. Initial echo area message. Not very important. > * 19. Terminal specific lisp library. This can be important if you use > terminal emulation and need one of these. I've never had to worry about > this. > * 18. Set the mode of *scratch*. > * 17. Run after-init-hook. > * 16. Set after-init-time. I think this is used in measuring how fast > Emacs init is. If you use after-init-hook or emacs-startup-hook then > the stuff in those isn't measured. In different situations you may want > that or not want it. You can always put everything into the init file > temporarily just to see how long the full init takes. > * 15. Initialize packages. This is important, packages aren't > initialized in the init file. There has been some discussion about > changing this. Many people change it by putting package-initialize in > their init file. > * 14. Load abbrevs. Abbrevs are rarely used programmatically so I > don't think this matters much. > * 13. Load "default" library. I've never used that. > * 12. Loading of the init file. -------------------------------------------------------- tl;dr Emacs package-managing emacs is thhe usual lure of Turing complete language= can=20 do anything does not mean doing it is appropriate. If we must use elisp for it, it would be good to have a separate 'binding-time'. Just as in the C world compile time and runtime are rigorously separated, it would be neat IMHO if elisp running in package-mgmt mode did it in batch-mode and required restart of emacs. Perhaps req-package is in the earlier binding time And use-package the later one?