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 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
