Re: windows installer

[Phillip Lord]

Eli Zaretskii <address@hidden> writes:

>> From: address@hidden (Phillip Lord)
>> Cc: address@hidden,  address@hidden,  address@hidden
>> Date: Fri, 10 Nov 2017 23:27:49 +0000
>> 
>> >> >  environment-variables on my Windows 10 test-machine: USERPROFILE (or
>> >> >  by concatenating HOMEDRIVE and HOMEPATH ).
>> >> 
>> >> I'll fix this.
>> >
>> > Just to make this more complex: the Windows platform conventions frown
>> > upon installing stuff in that directory; you are supposed to create a
>> > subdirectory and install there.
>> >
>> > And programs should not end up there, they should be under
>> > %ProgramFiles% instead.  The user's directory is for files, not for
>> > programs.
>> 
>> The disadvantage with ProgramFiles is that it requires elevation, which
>> user profile does not, although user profiles gets mixed up with
>> roaming. Although, elevation is pretty normal for installation. But I
>> didn't want to it straight away in case I made the uninstaller
>> accidentally delete my windows installation.
>
> I don't think I understand the last sentence.

"didn't want to do it", sorry.

The installer includes an uninstaller which recursively deletes the
directory tree. If I get it wrong, AFAICT, it will delete anything I
tell it to. Being elevated seems a bad thing during development.


> For the rest, installing into the user's profile because doing TRT is
> harder is not a sufficient reason in my book.  If you want to avoid
> elevation (which I don't think you should, given that this is "normal"
> Windows behavior nowadays), then install into a directory that is
> neither user profile nor Program Files (and maybe not even drive C:,
> if there is another drive).  But going to the user profile is highly
> unusual, to say the least.
>
>> > They _will_ want to add it to PATH if they want to install packages
>> > from the likes of ELPA, which frequently come with Makefiles that
>> > invoke Emacs to compile the Lisp files.
>> 
>> Really?
>
> AFAIU, yes.


I checked; the makefiles in ELPA are for the developers pleasure, not
users. The make file doesn't get pulled down, nor is it run client
side. MELPA is the same -- there is no build step from git source to end
package -- it's all just lisp.


> And even if ELPA packages have alternatives which don't invoke Make,
> there will be other situations where building a package with Emacs
> support will want to invoke Emacs.  One such example is GNU ID-utils.
>
> IOW, Emacs is not just a GUI application used interactively, it is
> also a program that supports batch-mode invocation, and that mode is
> at times used by other programs.  Keeping the Emacs binary off the
> users' system PATH is therefore less than ideal, because the users
> will then bump into subtle problems whereby Emacs seems "unavailable".

I suspect that these sort of users will install with the zip file or
equivalent.

Phil