[R-pkg-devel] Wrong mailing list: Could the 100 byte path length limit be lifted?

[Tomas Kalibera]

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.bayesian using gmail.com>
> Sent: Thursday, December 14, 2023 12:11 PM
> To: Vladimir Dergachev
> Cc: McGrath, Justin M; r-package-devel using 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 <volodya using mindspring.com<mailto:volodya using 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 using r-project.org<mailto:R-package-devel using 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 using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel