[Sbcl-devel] RFE: Quicklisp by default

[Mike Manilone]

Hi all,

Since Quicklisp is the most popular CL libraries manager, I've been
thinking it would be better if we provide Quicklisp by default.

Thanks.

Best Wishes,
Mike Manilone

[Stas Boukarev]

Mike Manilone <crt...@gmx.us> writes:

> Hi all,
>
> Since Quicklisp is the most popular CL libraries manager, I've been
> thinking it would be better if we provide Quicklisp by default.
>
> Thanks.

I don't think anybody has problems with downloading a single file and
loading it. Bundling it with SBCL just means that older releases will
have an outdated version of quicklisp.

--
With best regards, Stas.

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

[Mike Manilone]

於 二，2013-04-30 於 13:56 +0400，Stas Boukarev 提到：

> I don't think anybody has problems with downloading a single file and
> loading it. Bundling it with SBCL just means that older releases will
> have an outdated version of quicklisp.

That's just easier to get it working. quicklisp-client itself doesn't
get outdated so fast though. What's more, you can also use quicklisp to
update itself. :-/

[Zach Beane]

Mike Manilone <crt...@gmx.us> writes:

> Hi all,
>
> Since Quicklisp is the most popular CL libraries manager, I've been
> thinking it would be better if we provide Quicklisp by default.

The license doesn't preclude it, I hope this isn't done. I don't like
the notion that the instructions for setting up Quicklisp might diverge
depending on which implementation is used.

Zach

[Nathan Froyd]

Would quicklisp updates work properly for system-wide installs (i.e.
where the SBCL user doesn't have write permissions to SBCL_HOME)? If
not, then we'd have to convince Zach to include such functionality
(unlikely, since he's already expressed disinterest in having
quicklisp included in the first place) or write such functionality
ourselves, which defeats the purpose of bundling, IMHO.

If such updates did work, then we're back to square one, of course.

-Nathan

[Zach Beane]

Nathan Froyd <fro...@gmail.com> writes:

> On Tue, Apr 30, 2013 at 6:18 AM, Mike Manilone <crt...@gmx.us> wrote:
>> 於 二，2013-04-30 於 13:56 +0400，Stas Boukarev 提到：
>> > I don't think anybody has problems with downloading a single file and
>> > loading it. Bundling it with SBCL just means that older releases will
>> > have an outdated version of quicklisp.
>>
>> That's just easier to get it working. quicklisp-client itself doesn't
>> get outdated so fast though. What's more, you can also use quicklisp to
>> update itself. :-/
>
> Would quicklisp updates work properly for system-wide installs (i.e.
> where the SBCL user doesn't have write permissions to SBCL_HOME)? If
> not, then we'd have to convince Zach to include such functionality
> (unlikely, since he's already expressed disinterest in having
> quicklisp included in the first place) or write such functionality
> ourselves, which defeats the purpose of bundling, IMHO.

It doesn't work well for a site-wide installation. It's something I'd
like to support in some way, or at least not accidentally thwart, but
it's not working today.

Zach

[Nikodemus Siivola]

I think having a lightweight HTTP client bundled might be a nice
halfway house between bundling Quicklisp and leaving it all to user. A
sketch called SB-HTTP is in here: https://github.com/nikodemus/sb-http

Enough to make

(with-open-stream (s (sb-http:get "http://beta.quicklisp.org/quicklisp.lisp"))
(load s))

work, but not much else. If someone wants to take it and run with it...

Cheers,

-- nikodemus

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.

Download for free and get started troubleshooting in minutes.

http://p.sf.net/sfu/appdyn_d2d_ap2

[Nikodemus Siivola]

On 3 May 2013 17:56, Zach Beane <xa...@xach.com> wrote:
>> I think having a lightweight HTTP client bundled might be a nice
>> halfway house between bundling Quicklisp and leaving it all to user.
>

> This would work even better if it was a HTTPS client. It seems like a
> hairy thing to me, but would be nice to lift this responsibility from
> the user.

I agree 100%, which is one of the reasons I haven't pushed it as a
contrib -- not sure what to do about SSL.

[Zach Beane]

Nikodemus Siivola <niko...@random-state.net> writes:

> I think having a lightweight HTTP client bundled might be a nice
> halfway house between bundling Quicklisp and leaving it all to user.

This would work even better if it was a HTTPS client. It seems like a
hairy thing to me, but would be nice to lift this responsibility from
the user.

Zach

[Robert Goldman]

Nikodemus Siivola wrote:
> On 3 May 2013 17:56, Zach Beane <xa...@xach.com> wrote:
>>> I think having a lightweight HTTP client bundled might be a nice
>>> halfway house between bundling Quicklisp and leaving it all to user.
>> This would work even better if it was a HTTPS client. It seems like a
>> hairy thing to me, but would be nice to lift this responsibility from
>> the user.
>
> I agree 100%, which is one of the reasons I haven't pushed it as a
> contrib -- not sure what to do about SSL.

Possibly a stupid question: doesn't Drakma come with SSL support?
Could that be bundled rather than rolling a new HTTP client?

[Luís Oliveira]

On Fri, May 3, 2013 at 5:35 PM, Robert Goldman <rpgo...@sift.info> wrote:
> Possibly a stupid question: doesn't Drakma come with SSL support?
> Could that be bundled rather than rolling a new HTTP client?

Drakma depends directly or indirectly on alexandria, babel, cffi,
chunga, cl+ssl, cl-base64, flexi-streams, puri, split-sequence,
trivial-features, trivial-gray-streams, and usocket. That amount of
dependencies makes it harder to bundle conveniently.

--
Luís Oliveira
http://r42.eu/~luis/

[Faré]

Why are dependencies a problem? As long as they can be hot-upgraded
without breaking the system and/or that there exist some system like
the Symbolics "syntax" mechanism that allows for multiple name
mappings to packages to coexist, then we can both import plenty of
dependencies and not infringe on the user's ability to load
incompatible versions.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
As the Chinese say, 1001 words is worth more than a picture. — John McCarthy

[Nathan Froyd]

On Fri, May 3, 2013 at 8:43 PM, Faré <fah...@gmail.com> wrote:
> Why are dependencies a problem? As long as they can be hot-upgraded
> without breaking the system and/or that there exist some system like
> the Symbolics "syntax" mechanism that allows for multiple name
> mappings to packages to coexist, then we can both import plenty of
> dependencies and not infringe on the user's ability to load
> incompatible versions.

Dependencies are an important point of concern. My interpretation of
Luis's point was simply an acknowledgement of the sheer amount of code
that would be required by including Drakma in the SBCL distribution.
Maintainers would then be responsible for pulling in new versions,
compatibility testing, etc. etc. Requiring that much code merely so
people can download quicklisp (which then obsoletes, or nearly so, all
that code) with a one-liner doesn't seem like progress.

-Nathan