On Mon, Oct 23, 2017 at 12:27 PM, Emmanuel Charpentier
<emanuel.charpent...@gmail.com> wrote:
>
>
> Le lundi 23 octobre 2017 12:17:06 UTC+2, Erik Bray a écrit :
>>
>> On Mon, Oct 23, 2017 at 11:57 AM, Emmanuel Charpentier
>> <emanuel.c...@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...
>
>
> ...which is *exactly* my point !
>
> Presently, the only reason ever given to this patch (which lifts upstream
> R's requirement on an https-enabled library) is to be able to build Sage
> without OpenSSL because it's not, in some eyes, GPL-compatible.
>
> I balk at the idea of maintaining this patch again and again for this issue,
> which can be solved either by depending on a systemwide openssl (but there
> goes our "batteries included" philosophy) or including OpenSSL (currently
> not possible for licensing reasons, but that should change).
I agree.
> I also balk at the idea of shipping a crippled pip.
It's not crippled if you don't need it to install from HTTPS which not
everyone does.
Okay. I think I see the problem here. We're talking about multiple
issues simultaneously and some things are getting confused--some
streams crossed.
First: There is the *general* issue of whether or not these packages
need any kind of SSL support in order to function. This is an issue
*completely* independent from Sage (except insofar as we may or may
not need to maintain some patches to ensure that they don't require
SSL, but that is a separate issue that I will get to next). From the
general standpoint of pip's design and functionality, it does not in
any way require SSL to work. There was a time when it did, but only
due to a bug where some module assumed the `ssl` module would always
be importable which is not necessarily the case. There are completely
legitimate reasons to either *explicitly* run pip without SSL support,
and there are completely legitimate reasons to simply not need it at
all or not care. Therefore pip should be able to work (and does)
without SSL support, without patching. The same should be true for R,
and if this is not the case (and I'm not convinced it isn't), then it
should be for the same or similar reasons as pip. Again, this is
purely from an abstract standpoint in how that software should,
ideally, be designed.
Second: The question is, should it be possible to build/install Sage
(specifically the distribution) without an SSL library? There are two
sub-problems that arise from this question:
a) If we agree that that should at least be *possible* (I think it
should be, even if not the default) to build Sage without SSL, then
all of Sage's dependencies should be able to build without SSL. This
includes pip and R. If these packages satisfy the first issue then
there is no problem; nothing to discuss. But your assertion is that R
can't even be built without SSL support unless it is patched. I would
consider that an upstream deficiency that should be addressed
aggressively just in principle if nothing else.
b) If we agree that it should not be possible to build Sage
without SSL support (which I think is a poor decision, due to the
first point) then there is no issue about needing to maintain a patch
to remove SSL requirement from any package. But there is the separate
issue of having this added dependency that may be inconvenient for
some people.
Third: There's a question of who the audience is. For the "casual"
user who does not care about building things or compiling things or
licenses or patches and just wants to run Sage, and be able to install
packages from pip and CRAN (should the need even arise) this should
all Just Work. From that point of view, they should be installing
Sage from pre-built binaries, and those binaries should include the
necessary SSL support, period, end of story. This requirement is
independent of how SSL support is achieved, what that means for
developers or maintainers of binary packages, etc.
Does that help at all?
I think we're nearly in agreement, except maybe about the extent to
which SSL support should be mandated in all cases.
Best,
Erik
--
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.
