On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier <emanuel.charpent...@gmail.com> wrote: > Dear Erik, > > Le lundi 23 octobre 2017 11:16:05 UTC+2, Erik Bray a écrit : >> >> On Thu, Oct 19, 2017 at 5:19 PM, Emmanuel Charpentier >> <emanuel.c...@gmail.com> wrote: >> > Again : R is not only a software package but also an ecosystem. The >> > 11638 >> > (as of today) packages available to R users are a large part of R >> > usefulness >> > to its users. So, "disabling downloads from CRAN" is *NOT* fine (to >> > them, at >> > least...). >> >> I'm not saying it shouldn't be possible to install R packages at all, >> any less than it should be possible to install Python packages. My >> point here was that with Python, for example, one can manually >> download a package tarball or wheel from PyPI using, say, curl for >> example (maybe if they running on an air-gapped network this was done >> on a separate machine and sneaker-netted over, etc.). pip can then >> install from the manually downloaded package file. >> >> I don't know if the same is possible with R but you'd think it should >> be. However R installs packages the sequence still has to be >> something like >> >> 1) Download package from CRAN >> 2) Verify that package downloaded successfully (maybe it does this >> maybe it doesn't) >> 3) Install the package >> >> So it should be possible to do steps 1 and 2 manually, and then skip >> straight to 3. Admittedly running R on an air-gapped network is >> probably not a situation the developers have in mind but I have very >> little doubt that the use case exists. > > > Indeed, it *is* possible to install a manually downloaded package (not as > straightforward as the automatic download-and-install default method). But > the problem isn't here : > > There are a large number of CRAN packages (11660 as of this morning). More > and more of these packages have mutual dependencies, which are easily > accounted for bu install.packages() but are a pain to deal with "manually". > > In fact, the problem (roughly) has same magnitude as the maintainance of > your operating system : it *is* indeed possible to maintain a Unix/Linux > installation using only tarballs conveyed to the system via sneakersnet, but > it' certainly a) not fun and b) chronophage to the extreme... > > As it happened with Linux distributions, these intermutual dependencies, > which started scarce and lightweight, are getting more and more important. > My prediction (or prognostication, or oracle, if you wish...;-) is that they > will reach the level of complexity of operating system distributions in an > amount of time short enough for this problem to be of interest to all but > the oldest (i. e. closest to retirement or death) of R users.
I understand all that, and the same is true of some Python packages as well (which is why sometimes Sage winds up having to add quite a few spkgs for Python packages--see for example the dependencies of Flask). But that's simply a matter that has to be dealt with, and people do (*I* do, even, in some cases). My point here is not that that that's a nice thing to foist on average users (it isn't). Just that it *should* be possible regardless, without patching or anything else. My concern is just why are we maintaining a patch just to be able to build R without SSL... -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
