On 12/14/23 19:39, McGrath, Justin M wrote:
At this point, the policy appears to have nothing to do with tar, contrary to
the error message. Thus, replacing tar with zip wouldn't address CRAN's
concern. The policy given in this thread (and seemingly unstated anywhere
public) is that CRAN wants to allow someone on Windows to unpack an R package
in a directory with a path length of 160 characters, given the 260 limit on
Windows.
The CRAN repository policy is a publicly accessible document at [1]. If
you are unsure what is acceptable or not, or if you think you a have
strong case to ask for an exception for your package, or possibly for
completely ignoring this warning from R, contact the CRAN team [2].
On this list you may receive help and advice from individual people, but
that doesn't constitute the CRAN policy nor what CRAN "wants", even when
from people who individually are members of the CRAN team. You may still
find such advice useful for making your packages better.
If you wanted R tar() to stop issuing warnings in certain cases, you can
suggest that on R bugzilla. If that happens and instead say a new check
is added to R to warn when a different limit is reached (e.g. to protect
users on Windows), you can then file another bug report.
I don't think you can get any more help with this on this list.
1. https://cran.r-project.org/web/packages/policies.html
2. https://cran.r-project.org
Tomas
The implication here is that developers of public libraries needs to get their
act together because they have *total path lengths* of 85 characters, that one
needs to rename to include in an R package, in order to accommodate someone
who is unpacking R packages in directories with lengths of 160 characters (just
the directory length!). I doubt such people exist, so we are accommodating a
myth. I don't even have directories that long on my computer, and I certainly
wouldn't be unpacking R packages in them if I did.
Path lengths in packages of 130 to 150 characters would allow unpacking in
directories of 130 to 110 characters. Anything in that range would likely
result in no or very few problems for either the people creating or the people
unpacking packages. The claim that people need to use sensible naming schemes
goes both ways. One can't expect unreasonably long path in packages, and people
making packages can't expect people try to unpack into unreasonably long
directories. Yet, it's impossible to miss the great disparity in the current
split of 100 character total path vs 160 characters for just a directory path.
________________________________________
From: Steven Scott <steve.the.bayes...@gmail.com>
Sent: Thursday, December 14, 2023 12:11 PM
To: Vladimir Dergachev
Cc: McGrath, Justin M; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Wrong mailing list: Could the 100 byte path length
limit be lifted?
Compiled code is another source of long names. Some libraries are produced by companies
with style restrictions that demand LongDescriptiveNames for functions and classes, and
which expect file names to match the name of the class contained within. If you've got
Models/SpecificModelFamily/PosteriorSamplers/SpecificTypeOfPosteriorSampler.hpp it leaves
very little room (20 characters) for "C:\Users\..." etc up front.
I solved my 'tar' problems with 'sed'. In human readable code I keep the long
names. In the code that gets submitted to CRAN I pass specific file names
through sed to rename the long files. I have an install script with lines like:
hdr="MvStateSpaceRegressionPosteriorSampler.hpp"
new_hdr="MVSSRPS.hpp"
mv "$ibase/$dbase/$hdr" "$ibase/$dbase/$new_hdr"
echo "replacing $dbase/$hdr with $dbase/$new_hdr"
grep -rl "$dbase/$hdr" "$BOOM_DIR/src/Models" | xargs $SED -i
"s|$dbase/$hdr|$dbase/$new_hdr|g"
This renames the files, and uses sed to replace #include references to file
names with the shorter file names. The SED macro is because on mac 'sed' is
spelled 'gsed'.
I agree the system sucks. It would be nice if one of the steps in winbuilder took
non-windows compliant TAR files and replaced them with ZIP files or something
similar. We'd still have the Win32 character limit, but 256 > 100 so the
problem wouldn't bite so hard.
On Thu, Dec 14, 2023 at 6:19 AM Vladimir Dergachev
<volo...@mindspring.com<mailto:volo...@mindspring.com>> wrote:
On Wed, 13 Dec 2023, McGrath, Justin M wrote:
On Windows, packages will be in "C:\Users\[User Name]\Documents\R\win-library\[R
version]\[Package Name]".
With a 150 byte limit, that leaves 70 bytes for the user name, R version
and package name. That seems more than sufficient. If people are
downloading the source files, that also leaves plenty of space
regardless where they choose to extract the files.
70 bytes ?? My name is 18 characters long and there are plenty of people
with longer names. I also saw practice on Windows systems to append the
name of organization or department.
Also, this restricts the length of package name which is arguably more
important that internal package path names that the user never sees.
That said, that Windows limitation is only for some programs, and the
pertitent question is whether R and any software used by R has this
limitation. I suspect the answer is no, but as all my systems are Linux
I can not check.
Vladimir Dergachev
______________________________________________
R-package-devel@r-project.org<mailto:R-package-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel<https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!DZ3fjg!93aINLPSC17ykCzT_i1DXmJ-yJAMwt2qaA6IIJjoA4XZP-dDbg_gZp8N-nN9Mcfpw4nR1wc--NRqfx6iGnr6OLa0XJUUKQ$>
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
