On 7 December 2017 at 17:56, Tomas Kalibera wrote:
|
| An update on this. Writing R Extensions does not recommend to have a
| space character in R_HOME. This means that on Windows one either should
| have SFN enabled (which is still the common case), or install into a
| directory that does not have a space in its name (so specifically not
| into "Program Files"). This recommendation unfortunately needs to
stay
| for now.
|
| WRE recommends that Makefiles are written to be robust against space
| characters inside R_HOME. All path names passed from a Makefile to the
| shell should be quoted at least if they include R_HOME. Make
"include"
| directives should not be used on path names that are derived from
| R_HOME, but one should instead use the "-f" option multiple times
when
| recursively invoking make. Maintainers of packages that use
"include"
| with R_HOME have been notified. Unfortunately, the number of packages
| that do not quote pathnames with R_HOME in Makefiles is rather large, so
| fixing will take some time.
|
| Currently, R-devel should build fine on Windows with R_HOME including
| space, including all base and recommended packages, and tests for these
| packages should pass even though this is not regularly tested. If you
| find a case when this does not work, please submit a bug report.
Why does the Windows installer default to using a directory with spaces?
Related (but moderately more advanced), why does R still install
"everything"
under one (versioned) directory so that uninformed users on upgrade
"miss"
all previously installed packages?
Why not (with space for exposition here, imagine s/ // everywhere below)
$SOMEROOTDIR / R /
R-a.b.c/ # before
R-a.b.d/ # d > c, here
site-library/ # with .libPaths having this preset?
I don't really care as I manage to work mostly / entirely on another OS, but
I just don't understand why we do not put two and two together. But I am
likely unaware of some salient issues.
In any event, I appreciate the thankless work of those taking care of Windoze
(ie Tomas, Jeroen, Duncan (now ex-officio), Brian, ...)
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
On 12/07/2017 06:15 PM, Dirk Eddelbuettel wrote:> On 7 December 2017 at 17:56, Tomas Kalibera wrote: > | > | An update on this. Writing R Extensions does not recommend to have a > | space character in R_HOME. This means that on Windows one either should > | have SFN enabled (which is still the common case), or install into a > | directory that does not have a space in its name (so specifically not > | into "Program Files"). This recommendation unfortunately needs to stay > | for now. > | > | WRE recommends that Makefiles are written to be robust against space > | characters inside R_HOME. All path names passed from a Makefile to the > | shell should be quoted at least if they include R_HOME. Make "include" > | directives should not be used on path names that are derived from > | R_HOME, but one should instead use the "-f" option multiple times when > | recursively invoking make. Maintainers of packages that use "include" > | with R_HOME have been notified. Unfortunately, the number of packages > | that do not quote pathnames with R_HOME in Makefiles is rather large, so > | fixing will take some time. > | > | Currently, R-devel should build fine on Windows with R_HOME including > | space, including all base and recommended packages, and tests for these > | packages should pass even though this is not regularly tested. If you > | find a case when this does not work, please submit a bug report. > > Why does the Windows installer default to using a directory with spaces?It's a convention on Windows and I guess there may be problems with permissions on other directories. My hope is we can make R work reliably without SFN just in time before SFN become disabled by default, after all, quoting pathnames in Makefiles (or shell scripts for that matter) is a good practice anyway and avoiding "include" is not a big problem as very few packages are affected. But thanks for opening this and I am happy for insights from any Windows experts on the issue. I would not want to violate the convention for all users when just few of them have SFN disabled, and as I hope this will be fixed on R/packages side, but maybe the installer could at least detect the problem (when "Program Files" or another specified target directory did not have a short name). Or perhaps also suggest a different default. Certainly R could print a warning when it starts. Tomas> Related (but moderately more advanced), why does R still install "everything" > under one (versioned) directory so that uninformed users on upgrade "miss" > all previously installed packages? > > Why not (with space for exposition here, imagine s/ // everywhere below) > > $SOMEROOTDIR / R / > R-a.b.c/ # before > R-a.b.d/ # d > c, here > site-library/ # with .libPaths having this preset? > > I don't really care as I manage to work mostly / entirely on another OS, but > I just don't understand why we do not put two and two together. But I am > likely unaware of some salient issues.> > In any event, I appreciate the thankless work of those taking care of Windoze > (ie Tomas, Jeroen, Duncan (now ex-officio), Brian, ...) > > Dirk >
For what it's worth, the Windows installers for other programming
language runtimes often install outside of Program Files, so at least
there is 'prior art' to motivate having R install directly into the
root of the home drive:
- ActiveState Perl installs directly C:/Perl;
- Python installs (when installing for all users) into C:/Python$VERSION;
- The Ruby installers at https://rubyinstaller.org/ default to the
root home drive.
So I (as Dirk said earlier) would also be in favor of having R install
directly to the root of the home drive, with e.g. C:/R/R-x.y.z being
the default install location.
Best,
Kevin
On Fri, Dec 8, 2017 at 4:14 AM, Tomas Kalibera <tomas.kalibera at
gmail.com> wrote:>
> On 12/07/2017 06:15 PM, Dirk Eddelbuettel wrote:
>>
>> On 7 December 2017 at 17:56, Tomas Kalibera wrote:
>> |
>> | An update on this. Writing R Extensions does not recommend to have a
>> | space character in R_HOME. This means that on Windows one either
should
>> | have SFN enabled (which is still the common case), or install into a
>> | directory that does not have a space in its name (so specifically not
>> | into "Program Files"). This recommendation unfortunately
needs to stay
>> | for now.
>> |
>> | WRE recommends that Makefiles are written to be robust against space
>> | characters inside R_HOME. All path names passed from a Makefile to
the
>> | shell should be quoted at least if they include R_HOME. Make
"include"
>> | directives should not be used on path names that are derived from
>> | R_HOME, but one should instead use the "-f" option multiple
times when
>> | recursively invoking make. Maintainers of packages that use
"include"
>> | with R_HOME have been notified. Unfortunately, the number of packages
>> | that do not quote pathnames with R_HOME in Makefiles is rather large,
so
>> | fixing will take some time.
>> |
>> | Currently, R-devel should build fine on Windows with R_HOME including
>> | space, including all base and recommended packages, and tests for
these
>> | packages should pass even though this is not regularly tested. If you
>> | find a case when this does not work, please submit a bug report.
>>
>> Why does the Windows installer default to using a directory with
spaces?
>
> It's a convention on Windows and I guess there may be problems with
permissions on other directories. My hope is we can make R work reliably without
SFN just in time before SFN become disabled by default, after all, quoting
pathnames in Makefiles (or shell scripts for that matter) is a good practice
anyway and avoiding "include" is not a big problem as very few
packages are affected.
>
> But thanks for opening this and I am happy for insights from any Windows
experts on the issue. I would not want to violate the convention for all users
when just few of them have SFN disabled, and as I hope this will be fixed on
R/packages side, but maybe the installer could at least detect the problem (when
"Program Files" or another specified target directory did not have a
short name). Or perhaps also suggest a different default. Certainly R could
print a warning when it starts.
>
> Tomas
>>
>> Related (but moderately more advanced), why does R still install
"everything"
>> under one (versioned) directory so that uninformed users on upgrade
"miss"
>> all previously installed packages?
>>
>> Why not (with space for exposition here, imagine s/ // everywhere
below)
>>
>> $SOMEROOTDIR / R /
>> R-a.b.c/ # before
>> R-a.b.d/ # d > c, here
>> site-library/ # with .libPaths having this
preset?
>>
>> I don't really care as I manage to work mostly / entirely on
another OS, but
>> I just don't understand why we do not put two and two together. But
I am
>> likely unaware of some salient issues.
>
>
>>
>> In any event, I appreciate the thankless work of those taking care of
Windoze
>> (ie Tomas, Jeroen, Duncan (now ex-officio), Brian, ...)
>>
>> Dirk
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel