From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Radon Rosborough Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Fixing package-initialize, adding early init file Date: Mon, 25 Sep 2017 15:16:40 -0700 Message-ID: References: <87d16exyk5.fsf@udel.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1506377922 5363 195.159.176.226 (25 Sep 2017 22:18:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 25 Sep 2017 22:18:42 +0000 (UTC) Cc: jwiegley@gmail.com, Stefan Monnier , emacs-devel@gnu.org To: Mark Oteiza Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 26 00:18:34 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dwbhy-0000cS-6a for ged-emacs-devel@m.gmane.org; Tue, 26 Sep 2017 00:18:34 +0200 Original-Received: from localhost ([::1]:44536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwbi2-0006kG-7h for ged-emacs-devel@m.gmane.org; Mon, 25 Sep 2017 18:18:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwbgq-0006hU-3x for emacs-devel@gnu.org; Mon, 25 Sep 2017 18:17:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dwbgo-0006ZJ-Ko for emacs-devel@gnu.org; Mon, 25 Sep 2017 18:17:24 -0400 Original-Received: from mail-wr0-x229.google.com ([2a00:1450:400c:c0c::229]:53646) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dwbgo-0006Z9-Bs for emacs-devel@gnu.org; Mon, 25 Sep 2017 18:17:22 -0400 Original-Received: by mail-wr0-x229.google.com with SMTP id l22so10415585wrc.10 for ; Mon, 25 Sep 2017 15:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nXK1UFFkNIiBs1ANNlTP59L59wqNkJ1c7qPldZciEAE=; b=Vj9ZmTqIpq8Jqp5TwAPbbo5OgeSsotC/r+0TANm05WrN91KIrez6BVKZ5oGHIsJ0VJ i6LBH3ujYdpsd+eoxt0lpIlZLrthCpI1xyQFVv9K/00VGyS4jfmAnq/KB4ajlQg2wEsE 4xsJAWq11fHJGODy52V2yyZZ1BwD2oAGeinDPYKueVWxuIJiznysTBcFQUHcQjdWK4ez AbxnuAam7aDgZaJIUWT1DiNUkGMFJ7Ve6RjK7l4EAeLqT5myBfa21NJxBVBE9qBHoruB xMTo0Fvd4EswWJn2K6hz8607ezbvV1jQjvPYdtpz2RS5N/jgkaq+l3/x4lQtFjJsVPf4 aXvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nXK1UFFkNIiBs1ANNlTP59L59wqNkJ1c7qPldZciEAE=; b=pOLlvK6zdZY3nsBEdBR4t4F30gvqRZGEIDVxukIS209IJbrV9Un5zKGpIhxVn6EJ8t V8RjoQFzhK/K2kDN02jK6OPvacPhetHfZnP67OyEjTkJqmdwv8rr2/YXtWTMfl5OEg92 TR6lQSWB39iC0Bd/wLxHLMaJdRnLEPivsAs09gJwId081iwpkaE/qDEtYCcJFh8OtN+Z SS6FW8cSRmOPMd1GXNISo6ItzH+VYJQqkSSv6QfezMCkrAzOFCjGs1S1+ZtF31/3JB9O axgl0u3RmysNvCPCkzweRMy1jG/OCahzB3lm3UKdW25zzPg5vLSFPg2YESoFWt4qv558 m0Tg== X-Gm-Message-State: AHPjjUjXWu+0LPwG+5V3w3/BWJHNuPS+MBmDBuyfg7X3kbcOmJYXtCCb RxLhslvqaDkv4etAZUD2TO829EsfzOR12D5KB5Y= X-Google-Smtp-Source: AOwi7QCl/+uqefbQgWzwe7J8AsT+bMq15Qt5v2ebs5lVcWafmIp36Q+EMQ1rf4p5D+AWE2EE2zlA9aYrV/uoDW02Ito= X-Received: by 10.25.15.22 with SMTP id e22mr2574967lfi.16.1506377841131; Mon, 25 Sep 2017 15:17:21 -0700 (PDT) Original-Received: by 10.25.22.76 with HTTP; Mon, 25 Sep 2017 15:16:40 -0700 (PDT) In-Reply-To: <87d16exyk5.fsf@udel.edu> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:218788 Archived-At: > I haven't seen one place where the problem_s_ involved have been > clearly articulated As for the problems with the current situation, check out [1] and also the section for Proposal A in [2]. But again, I'll re-summarize: * Emacs modifies the init-file automatically, without asking the user. * If the user has set any variables related to package.el in their init-file, then Emacs will modify the init-file to do the wrong thing! Unless by "problems involved" you meant more generally, for all the different proposals? That is exactly what [2] was intended to cover; could you clarify what exactly you would like articulated that hasn't been already? > this patch does not improve any of the places where user facing > documentation was lacking in the first place Actually, I'd disagree. I think this patch improves the situation, not by adding more documentation, but by reducing complexity and therefore reducing the need for additional documentation. In particular, we no longer need to document the placement of (package-initialize) in the init-file, as such placement is no longer necessary. > requires the user to not only understand the forms that must be in > an init file Could you clarify what you mean by this? This patch has the effect that users can put package configuration right into their init-file, or use Custom to achieve the same, without having to know anything about the package system. If on the other hand "forms" is referring to 'setq' forms that customize the package system itself, then indeed, users must know to put them into a different init-file. However, I'd argue that this isn't much worse than the current situation, where users must know to put them *before* (package-initialize), and they must also know that Emacs will put (package-initialize) in the wrong place with regard to these customizations. > The whole discussion and push for a "solution" is predicated on > users who can't be bothered to do things correctly _not_ having to > do any configuration. This patch does not improve things in this > regard Correct. The current behavior is that things work out of the box, and this patch *maintains* that behavior. Since things already work out of the box, I don't see how you expect this patch to somehow improve that particular aspect any further. What this patch accomplishes is eliminating the problems inherent in automatic modification of the init-file, *without* losing the goal of the package system working out of the box. > The whole discussion and push for a "solution" is predicated on > users who can't be bothered to do things correctly _not_ having to > do any configuration [...] and frankly I don't see that predicate as > a good one for devising a solution. The goal is that when someone uses M-x package-install to install a package, and then they paste some Lisp code from the project's README into their init-file, then it works as expected. I think this is desirable behavior, and I think most everyone else thinks this is desirable behavior as well. That's why the current solution was put in in the first place, because people really wanted that use case to "just work". This patch achieves that same goal in a better way. > AIUI it still breaks existing config of package-archives, > package-load-list, etc, which is something the incumbent solution > also breaks. Correct, but here is the important point: it will only do so *once*, when people upgrade to Emacs 26. As opposed to the current solution, which breaks existing config every time (package-initialize) is inserted, which may happen many times for a given user. So this patch is a definite improvement. > The only proposal I can support at this time is reverting the > incumbent solution, yet none from the maintainership is willing to > entertain the idea. That's because it would result in the built-in package manager not working out of the box, which would be embarrassing from a UX perspective. That's the whole *point* of having a built-in package manager: that it works right away without additional setup. > I think adding another init file is unacceptable. Why? (Especially given that being able to run code before the first graphical frame is initialized would be super useful for lots of reasons, entirely separate from the package system.) [1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html [2]: https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00023.html