( )⚙ D7168 packaging: install .rc files to hgrc.d

This is an archive of the discontinued Mercurial Phabricator instance.

packaging: install .rc files to hgrc.d
ClosedPublic

Authored by indygreg on Oct 23 2019, 9:54 PM.

Details

Summary

Currently, Inno installs these .rc files to a default.d
directory and WiX to a hgrc.d directory.

Mercurial automatically loads files in an hgrc.d directory
next to the executable and in an "internal" default.d directory.
This "internal" directory is util.datadir, which on Windows
installs made with py2exe is the directory containing hg.exe.
So on Windows both hgrc.d and default.d directories relative
to hg.exe are loaded.

For the install layout, I think it makes sense for hgrc.d to
be used, as that path is documented as non-internal. So this
commit changes the Inno install layout to use hgrc.d instead
of default.d.

.. bc::

Changed default config file location in Windows .exe installers

Mercurial's installer installs some default .rc config
files. Previously, these were installed in a default.d
directory. These are now installed in an hgrc.d directory.

Custom default.d/*.rc files should still be loaded. But it
is recommended to move these to hgrc.d/*.rc.

This change only affects the .exe installers (not the .msi
installers).

Diff Detail

Repository
rHG Mercurial
Branch
stable
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

indygreg created this revision.Oct 23 2019, 9:54 PM

I think this change (and the entire series) is great!

Custom default.d/*.rc files should still be loaded. But it
is recommended to move these to hgrc.d/*.rc.

Is it a good idea to encourage people to modify the installation directory? I thought it was off limits on Windows, though a custom file does seem to survive an uninstall/install cycle of thg.

I do miss having a global directory like /etc/mercurial/hgrc.d. Loading relative to the exe isn't exactly global, since a vanilla hg vs a thg install will use different directories. I wonder if we can slip in a global directory under %ProgramData% or %AppData% or similar.

Is it a good idea to encourage people to modify the installation directory? I thought it was off limits on Windows, though a custom file does seem to survive an uninstall/install cycle of thg.
I do miss having a global directory like /etc/mercurial/hgrc.d. Loading relative to the exe isn't exactly global, since a vanilla hg vs a thg install will use different directories. I wonder if we can slip in a global directory under %ProgramData% or %AppData% or similar.

I agree that we should consider a better solution here. The compatibility story on Windows is not great and there's lots of room for improvement.

Looking in %ProgramData% or %AppData% in addition to a directory next to the executable and in your home directory feels appropriate. As you say, it mirrors on POSIX works with /etc.

indygreg updated this revision to Diff 17402.Oct 24 2019, 11:34 PM

Is it a good idea to encourage people to modify the installation directory? I thought it was off limits on Windows, though a custom file does seem to survive an uninstall/install cycle of thg.
I do miss having a global directory like /etc/mercurial/hgrc.d. Loading relative to the exe isn't exactly global, since a vanilla hg vs a thg install will use different directories. I wonder if we can slip in a global directory under %ProgramData% or %AppData% or similar.

I agree that we should consider a better solution here. The compatibility story on Windows is not great and there's lots of room for improvement.
Looking in %ProgramData% or %AppData% in addition to a directory next to the executable and in your home directory feels appropriate. As you say, it mirrors on POSIX works with /etc.

@mharbison72, are you okay with what Greg says?

I'll queue the patches up but not including this one for now. Thank, Greg! I don't really know what all these patches do, but the commit messages sound reasonable :)

mharbison72 accepted this revision.Nov 8 2019, 8:09 PM

Is it a good idea to encourage people to modify the installation directory? I thought it was off limits on Windows, though a custom file does seem to survive an uninstall/install cycle of thg.
I do miss having a global directory like /etc/mercurial/hgrc.d. Loading relative to the exe isn't exactly global, since a vanilla hg vs a thg install will use different directories. I wonder if we can slip in a global directory under %ProgramData% or %AppData% or similar.

I agree that we should consider a better solution here. The compatibility story on Windows is not great and there's lots of room for improvement.
Looking in %ProgramData% or %AppData% in addition to a directory next to the executable and in your home directory feels appropriate. As you say, it mirrors on POSIX works with /etc.

@mharbison72, are you okay with what Greg says?
I'll queue the patches up but not including this one for now. Thank, Greg! I don't really know what all these patches do, but the commit messages sound reasonable :)

Yeah, I agree with that. My comment was mostly focused on what was to be indicated in the release notes.

Is it a good idea to encourage people to modify the installation directory? I thought it was off limits on Windows, though a custom file does seem to survive an uninstall/install cycle of thg.
I do miss having a global directory like /etc/mercurial/hgrc.d. Loading relative to the exe isn't exactly global, since a vanilla hg vs a thg install will use different directories. I wonder if we can slip in a global directory under %ProgramData% or %AppData% or similar.

I agree that we should consider a better solution here. The compatibility story on Windows is not great and there's lots of room for improvement.
Looking in %ProgramData% or %AppData% in addition to a directory next to the executable and in your home directory feels appropriate. As you say, it mirrors on POSIX works with /etc.

@mharbison72, are you okay with what Greg says?
I'll queue the patches up but not including this one for now. Thank, Greg! I don't really know what all these patches do, but the commit messages sound reasonable :)

Yeah, I agree with that. My comment was mostly focused on what was to be indicated in the release notes.

Thanks! I'll queue the rest of the series as well then.

This revision was not accepted when it landed; it landed in state Needs Review.
This revision was automatically updated to reflect the committed changes.