>>>>> Martin Maechler writes: Friends, a few quick comments.
The package+version URL mechanism is documented in the CRAN mirror HOWTO <https://cran.r-project.org/mirror-howto.html>. I had initially thought that one should safely remove http parameters when using a https? repo URL, but the repo does not know whether it is accessed via https?:// or e.g. file://, the latter for a local mirror. I think it is better to do redirections in the file system and use the Path field in PACKAGES as necessary. E.g., to access all package_version.tar.gz source files for CRAN irrespective of whether in current or archive one could create a pool area with symlinks to the physical locations, and arrange to use the pool as the repo. -k >>>>> Lluís Revilla >>>>> on Thu, 4 Dec 2025 10:22:40 +0100 writes: >> Hi Jeroen and Martin (and other readers), >> I like this suggestion Jeroen, but I am not sure of the implications >> of enabling this beyond getting a valid file name locally on the >> computer. >> The File field is documented on tools::write_PACKAGES as "the >> filenames be included ... in the ‘PACKAGES’ file." (which might need a >> slight modification if this patch is implemented). >> What would parameters do on CRAN-like repositories? How would they >> alter the behaviour of the request of the package downloaded? >> The only idea I could think of is to control which/how packages are >> installed (as the name, version and file extension is still fixed on >> this patch). >> There are different methods used by CRAN-like repositories to control that: >> - CRAN handles parameters at the web server level not on the PACKAGES file: >> You can get a specific package version with >> https://CRAN.R-project.org/package=PKG&version=VER but doesn't install >> dependencies as it is understood as a single package. > Interesting; I have not yet seen this documented; how would it work? > (To me it looks that the "?...." part is completely > disregarded, at least when used in a web browser ...) >> - https://bioconductor.org recommends using BiocManager to point to >> the right CRAN-like repository. >> - The CRAN-like repositories from https://r-universe.dev don't >> redirect but use sha256 as File (as you are well aware). >> - https://rpkgs.com redirects to appropriate binaries based on the >> headers, installing a package and its dependencies for the right R >> version and OS. >> - https://r-multiverse.org/ has two repositories but doesn't redirect, >> or use headers to control packages served. >> CRAN's redirects work for a single package but the headers approach >> works smoother for more than one at the cost of user/R admin >> preparations. >> I am not sure if some of these repositories (or new ones) could >> benefit from this feature. >> But I don't see a back compatibility problem as this couldn't be used >> by repositories since it wasn't available. > Thank you, Lluís, for the (partial) summary of what different > CRAN-like repositories do. > To "back compatibility": We cannot know in how many different > ways install.packages() and update.packages() are used for, > e.g., site-internal (typically company internal) package > repositories. > It could well be that some of these also provide 'File' entries > with a "?" (possibly even with a different meaning than "url parameters"). > .. and their own setup code may rely on the long file names one > way or another. > On decent operating systems (e.g., Linux; possibly macOS) > filenames containing a `?` work without problems: > $ touch foo?bar > $ ls -lG foo?bar > -rw-r--r-- 1 maechler 0 5. Dec 09:38 'foo?bar' > Hence, unconditionally cutting such filenames (as in the > original proposal) will break such R code. > Hence, we want to allow back compatible behaviour, such that previous > "non-cutting" behaviour would still be possible; easy and > simple. I'd tend to agree that the new behaviour would still be default > Lastly, to Jeroen's question: Yes, of course, update.packages() can use > all arguments of install.packages() via `...` (I'd be sure you'd > know..). > I've documented it explicitly in help(update.packages), yesterday. > Martin >> El dc., 3 de des. 2025, 12:34, Jeroen Ooms <[email protected]> va >> escriure: >>> >>> On Wed, Dec 3, 2025 at 11:55 AM Martin Maechler >>> <[email protected]> wrote: >>> > >>> > >>>>> Jeroen Ooms >>> > >>>>> on Tue, 2 Dec 2025 22:33:05 +0100 writes: >>> > >>> > > Currently `download.packages()` copies the full `File` >>> > > field from the URL in PACKAGES, including http parameters, >>> > > as the local filename on disk. So for example, if the >>> > > `PACKAGES` file contains >>> > >>> > > Package: jsonlite Version: 2.0.0 File: >>> > > >>> > jsonlite_2.0.0.tar.gz?auth=blabla123&hash=79fad1b6092c1d1cc71e096d02cbc7618837fda1f90b61443f09adc25caab095 >>> > >>> > > Then the file is saved on disk not as >>> > > `jsonlite_2.0.0.tar.gz` but as the full url including `?` >>> > > and `=` and `&` characters which are not supported and >>> > > create corrupt files on some platforms. >>> > >>> > Yes... but why should a "CRAN-like repository" use such file names ? >>> >>> Such that we can host a "CRAN-like repository" on modern >>> infrastructure that may use this sort of URLs. >>> > I am considering, but still not convinced why it is needed (see above). >>> > Maybe I'm overlooking something ? >>> > Also, I'd have it as a switch (argument) of download.packages() in >>> > order to provide back compatibility [no need for a new patch, though !] >>> >>> The patch should not break functionality; it only fixes an edge case >>> where R would otherwise write to an illegal filename on disk. I am >>> guessing nobody has used this yet so I am not sure what would be the >>> value of back compatibility to ensure R keeps doing this. >>> >>> In either case the fix would only be useful if install.packages() >>> makes use of it. >>> >>> ______________________________________________ >>> [email protected] mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
