From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Phillip Lord Newsgroups: gmane.emacs.devel Subject: Re: [feature/internal-msys] thoughts of a more function windows package Date: Thu, 21 Jan 2021 21:37:57 +0000 Message-ID: <87o8higedm.fsf@russet.org.uk> References: <87pn2dq3xv.fsf@russet.org.uk> <83ft39hnk1.fsf@gnu.org> <87h7nppzjy.fsf@russet.org.uk> <838s90hhb6.fsf@gnu.org> <87zh1gircl.fsf@russet.org.uk> <83turofw8r.fsf@gnu.org> <87sg6v76fd.fsf_-_@russet.org.uk> <83czxy7530.fsf@gnu.org> <87zh12grzh.fsf@russet.org.uk> <83wnw659kw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13784"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 21 22:39:45 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l2hg9-0003TV-DL for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Jan 2021 22:39:45 +0100 Original-Received: from localhost ([::1]:44256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2hg8-000598-Gk for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Jan 2021 16:39:44 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34612) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2hfG-0004OZ-1s for emacs-devel@gnu.org; Thu, 21 Jan 2021 16:38:50 -0500 Original-Received: from cloud103.planethippo.com ([78.129.138.110]:45434) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2hfC-0005ys-Pu; Thu, 21 Jan 2021 16:38:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DOeo3EJ0i1/AQ35b67bkPgELQMsi0uqLgR8ucG9moh8=; b=3BqpHxfAtBjPhCul7mKGhT/6H rspt4drglI7f5Ejmcc64KKW+1VdRJ9yb/h1DzOy4JDtlA+Sz0lxp85SQ/+KuGbodKa2kmAlCuXEzP thjGZtXm0dXvA7X9Ay44OFxW4CbrHtGOv82InEwegpASV212kVpT79SWiD58wR18K6A50wawJ7euW 7PIHTjmODbKdd0XWpvhx7aDsCwPvjMQGl8wLgdLHEuLGQDFPjKcvjapnJOzNKuhqLPyp3kC1ouL4g psGYw7V56nWm52adftNIm/irJDuutEmYkZedg80zpIMAhtx6qj5MlA1HgXl1RnIXY2GGdoXxHH2O6 iQZpldEXQ==; Original-Received: from cpc142648-benw12-2-0-cust627.16-2.cable.virginm.net ([82.10.74.116]:39706 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l2heU-0002FV-7c; Thu, 21 Jan 2021 21:38:02 +0000 In-Reply-To: <83wnw659kw.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 21 Jan 2021 22:17:03 +0200") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk Received-SPF: none client-ip=78.129.138.110; envelope-from=phillip.lord@russet.org.uk; helo=cloud103.planethippo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263257 Archived-At: Eli Zaretskii writes: >> Considering just the .exe installer, at the end of the installation >> process, we would run Emacs with menu bar, scroll bar and everything >> switch off and run the command "w32-msys-internal-install-dialog". > > "We" being the installation process? IOW, this will start > automatically at the end of the normal installation? Yep. >> Emacs would say "do you want do install a handy collection of >> tools". User says "y", then Emacs downloads the latest msys2-date.xz, >> then unpacks it with xz. Emacs will run msys2.exe to initialize >> (hopefully without poping up windows if this will work). Then Emacs will >> run pacman to update and install. The user will see Emacs saying >> >> Would you like to install msys, and a handy set of tools (Y/n) >> Installing msys...done >> Updating msys...done >> Installing git...done > > First, why Git? This is a "normal" user, not an Emacs developer, > right? Git is a huge package (and comes with Vim on top of that), so > maybe reconsider that part. That's open for question. I'd have to think about the packages I would want to use. However, for me, git is one of the first commands that Emacs complains about the absence of; this is because I use Emacs on my windows build machine, of course, which contains the Emacs git repo. But, also because most IDEs come with the ability to interact with git off the shelf. I think Windows users will expect it. Yep, it's big. I get this before installation: 319 MB (335,214,637 bytes) and this after installation. 826 MB (866,624,644 bytes) My guess is that it's the co-install of perl that is causing this issue rather than vim. But, openssh comes for free with this. And "huge" is a relative term. An installation under 1Gb seems reasonable to me. > Next, by "msys" you mean all those non-native programs that depend on > msys-1.0.dll? That's again meant for MinGW developers, not "normal" > users. Yes. Because it's got all the packages and tools and as far as I can see, they work with Emacs. > And finally, which packages will pacman install? are you going to > provide some list of packages, and if so, what will be there? Yes. Initially hard coded into the Emacs install, we might turn the list of msys packages into an ELPA package. That way, we could update the list of tools supported, without updating the Emacs distribution. > (Btw, pacman can ask questions and prompt the user for confirmation, > but the way you invoke it in w32-msys-run doesn't seem to be prepared > for such interaction?) That's why I use "--no-confirm". I'm looking for the minimum here that does something usable. > One other aspect that bothers me is that if the user already has some > parts of MSYS/MinGW64 installed, they will now have two places with > DLLs, which is a step towards "DLL hell". Yes, it is. And indeed, the DLLs distributed in the Emacs distribution might well get duplicated in the msys install. But they would be in one place. My presumption is that people who use msys already would not want this, and it would not be forced upon them. >> We might create "internal-msys" package on ELPA which >> contains a standard set of packages and Emacs fixes to make it work, so >> it would be freely updatable. At which point the w32-msys-install >> command would install the ELPA package before doing anything else. > > Is it really possible for us to distribute MSYS, given its license? You misunderstand, my poor wording. The ELPA package would not contain msys, but would contain list of msys package names and supporting code. Msys would come from the msys2 repo. >> > Btw, I don't think I understand why you insist on using 'concat' to >> > generate files names from 2 components: that's what expand-file-name >> > is for, and it does that better. >> >> Because in my own code, I tend to use f.el and I have got used to having >> a clean, consistent and comprehensive API, so I tend to forget the >> underlying Emacs primitives. > > Then I think f.el has a big problem. I was being slightly provocative; I shall divert the discussion no further. >> > One other not about the code you committed is that modifying PATH from >> > within Emacs is not generally a good idea, it has some subtleties. >> >> Any alternative that achieves the same thing? > > I think the only good idea here is to tell the user to amend PATH by > adding such-and-such directories to it. I don't like installers that > futz with my PATH, and would hate it if Emacs did that to others. > It's very easy to get that wrong, especially on Windows. There has to be a better way that this. Editing environment variables by hand is so last century. Of course, I do not want to edit the path globally. If I can do it in Emacs, then I would have to think of a different solution. Phil