From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark Oteiza Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Fixing package-initialize, adding early init file Date: Mon, 25 Sep 2017 19:15:03 -0400 Message-ID: <20170925231503.3tbg52ugrloxm4zb@logos.localdomain> References: <87d16exyk5.fsf@udel.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1506381374 29155 195.159.176.226 (25 Sep 2017 23:16:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 25 Sep 2017 23:16:14 +0000 (UTC) User-Agent: NeoMutt/20170912-13-728bb5 Cc: jwiegley@gmail.com, Stefan Monnier , emacs-devel@gnu.org To: Radon Rosborough Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 26 01:16:07 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 1dwcbf-00079D-Ab for ged-emacs-devel@m.gmane.org; Tue, 26 Sep 2017 01:16:07 +0200 Original-Received: from localhost ([::1]:44702 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwcbm-0005VH-9y for ged-emacs-devel@m.gmane.org; Mon, 25 Sep 2017 19:16:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dwcak-0005Tb-Rx for emacs-devel@gnu.org; Mon, 25 Sep 2017 19:15:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dwcag-0000hd-RB for emacs-devel@gnu.org; Mon, 25 Sep 2017 19:15:10 -0400 Original-Received: from mail-qt0-x22d.google.com ([2607:f8b0:400d:c0d::22d]:47210) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dwcag-0000gG-JB for emacs-devel@gnu.org; Mon, 25 Sep 2017 19:15:06 -0400 Original-Received: by mail-qt0-x22d.google.com with SMTP id b1so8652970qtc.4 for ; Mon, 25 Sep 2017 16:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=bIxeUWH238MfR9ZL4aHF0yAeDEgESZ0K0UWF3jcBviA=; b=BxALbELY/s7ezIM15ZilScjZezjhH6GjOR2fUZJgAsCPv7AYvi/M2zx3i0pU5420cQ DFy8nFKCM5zLu1C9iHpcwOsxwm4y+7ZhTWCZ9Mv9zpVE71lrHF04NqVBLV0Xq/4C0hhy XG+6HIG23rchmvLU+z6KQT4Ny7TKoxrlnSa3twUl77uJL5rXe9jbjgWDNDaQ4tqhdjUi GoyRSkpY0JC4Zy3e2lJwkRsR+zfXurvq/11qcoGwC0KEnOR4z/xm2VkdmGT8IRikT8HN z8Qs0x1qNQ/CFZ/DIeXuKdZjRktayILwQh3N3oFiTjv5j8ywedYrSHX/x5ZhG3n22Vmm l4PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=bIxeUWH238MfR9ZL4aHF0yAeDEgESZ0K0UWF3jcBviA=; b=q1aMz4P/w/t20yguWR5nwQMMeYuQmCmPjmPxKkCrTK4TV1k/AG3PyEk15TioLjLBC9 9Z+9u6aEFo0xcjRKJXz4Xsz8vGY3P0xItWJqT0jVgEbNA8GqBknSpK88Q5frmgFhi9cH piOgtR9Hyegda1BK2873xBZQ2Ncp4r/L0xF171OKx0mYO6g/GOXEmCY0iT1zf3iBwiwZ sHPgJtZ+/e7rWuPqFuq5QyDtzWpWwH15OknRaFOw/m5PizBi4EKLN8fxWld9vFi5aFNm Zn4SmrV++3KSC6wGqmhASSC6OFoxqmCndROvA7fHDo/vBFZwAAWQQtXMg6ZTFZ5ydhLA Rtsg== X-Gm-Message-State: AHPjjUg448W4xQah3HvSvL2WGXo30KqKHRL3zex7mybWPrZyJeHz6BEb wfFPPhXVFPP2yRSZGfJ5WEcseg== X-Google-Smtp-Source: AOwi7QCEk0kKRoRXvUpnQR+NHWO03NwWL5LMI9m63l2awlTbwaktTTCK6JkwsCdwh3nOywtEPCzfDA== X-Received: by 10.200.47.80 with SMTP id k16mr13336175qta.258.1506381305562; Mon, 25 Sep 2017 16:15:05 -0700 (PDT) Original-Received: from logos.localdomain (pool-173-67-36-61.bltmmd.fios.verizon.net. [173.67.36.61]) by smtp.gmail.com with ESMTPSA id g15sm5851350qtk.47.2017.09.25.16.15.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Sep 2017 16:15:04 -0700 (PDT) Content-Disposition: inline In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c0d::22d 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:218790 Archived-At: On 25/09/17 at 10:16pm, Radon Rosborough wrote: > > I haven't seen one place where the problem_s_ involved have been > > clearly articulated > > 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? I meant more explicitly--each of these use cases should be documented with examples. While the manual in its current state does explain things, it can be better. > > 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. The only documentation I see is in NEWS and the manual, which is where the old documentation was. > > 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. At the cost of users who customize package.el and don't need another init file. > 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) The current situation should never have happened. > > 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 Except for users who who don't need garbage dumped into their init file and for users who change their package archives or the list of activated packages in their init.el without the need of a package-initialize form because they read the docs. Apparently changing those custom variables is an edge case. https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00209.html > and > this patch *maintains* that behavior. which is why it gets a -1 from me. > > 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. An improvement from package--ensure-init-file is great, but that's still more breakage than prior to package--ensure-init-file. > > 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. Emacs itself doesn't work OOTB for most people. That it's customizable in Elisp is a feature.