Re: [feature/internal-msys] thoughts of a more function windows package

[Phillip Lord <phillip.lord@russet.org.uk>]

Eli Zaretskii <eliz@gnu.org> 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