From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Radon Rosborough Newsgroups: gmane.emacs.devel Subject: Re: Interoperation between package managers Date: Thu, 24 Aug 2017 13:11:24 -0700 Message-ID: References: <5e6faf18-5ace-80a4-9508-c723fedcbca4@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114a6a52336f9305578571b7" X-Trace: blaine.gmane.org 1503605605 7499 195.159.176.226 (24 Aug 2017 20:13:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2017 20:13:25 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Nikolay Kudryavtsev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 24 22:13:21 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkyUz-0000z7-E6 for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 22:13:05 +0200 Original-Received: from localhost ([::1]:50351 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkyV6-0002UN-0X for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 16:13:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkyU5-0002T4-5S for emacs-devel@gnu.org; Thu, 24 Aug 2017 16:12:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkyU3-00035i-Vt for emacs-devel@gnu.org; Thu, 24 Aug 2017 16:12:09 -0400 Original-Received: from mail-lf0-x236.google.com ([2a00:1450:4010:c07::236]:34729) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkyU3-00034q-JT for emacs-devel@gnu.org; Thu, 24 Aug 2017 16:12:07 -0400 Original-Received: by mail-lf0-x236.google.com with SMTP id d17so2247240lfe.1 for ; Thu, 24 Aug 2017 13:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NJolltEGWJyayurOKaXJAVQ80mPBPMPY/6zIjTL02o4=; b=cHDMoTW0ghdOEsmdJwk9WJPoC42O1ccolxNkhBEv2+4UY57RFXh3co+mMxDw9gFtQi /JvMhM0a9mXgs8MfLCFOOFkaCpn9JYWkVZXSXRFC4Ccuork4+/byQAPqmhXTYANLCqom HYG97wqyOTOS7yL74IUHp7Mw6RB/PZbQyhMm/a1hZpeejzCLUJcM6yNlvXS/dSLt5c2s RR2H5mbdPitSHWbsr5aejW9AmLHW8C4+qO3IShCDiBBwWfoaDxufIZ+KmDVIkmrNqfQx WwZwdOpETyfxN0F3OFlDZPVN+JrSqO3GO6REr9MlKuMJ8EADse+2CmYNsVq0x5YCa934 DiUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NJolltEGWJyayurOKaXJAVQ80mPBPMPY/6zIjTL02o4=; b=Fpj8c4OWdOvyWhOWAqmDcxFt5suagXVBofiI6fC8P+YG19K89rVJjrIK32gLPxlDww ik9I9jjxmsudgZeY6cGhXPR/PAdK2zv6iTBHAQqgt4AHZciXLagH2k4Q9acigI4iISdF c7/ew7RDO23sh3t8Lp2LAmiQGEDQvEef3rno+n0LGOaLEm2T3YGK+6AAI6x9nzFNcCPG y3I1Ycd9y1g/SEU8QPr6xQlDE0X+XnF18zXJn3VVKxvDN0AKGGDkqVtOpjDHL4Q5ucHx K57pWqidOttZWGa6h3wY4lVx7pUig6EFIuuz0wlh+nB2B5nzVB9DLnDW/vV1+gpS9xEy mRiw== X-Gm-Message-State: AHYfb5h/AIWkt4HurvuQPKFDdV1AI8zDIdARCHBqgS37MlOx7OAg3lq7 0XO9iibAR5aM5AMZR5GQXjRwadbIWLZEEh0u8w== X-Received: by 10.46.5.67 with SMTP id 64mr2537627ljf.157.1503605525014; Thu, 24 Aug 2017 13:12:05 -0700 (PDT) Original-Received: by 10.25.42.215 with HTTP; Thu, 24 Aug 2017 13:11:24 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217786 Archived-At: --001a114a6a52336f9305578571b7 Content-Type: text/plain; charset="UTF-8" > The main benefit of such API would be interoperability between > package managers. So to be clear, I like this proposal. But I'd like to ask whether it will really offer a lot of benefit over the current situation. Specifically: > allowing for complex cases like when you want some package from > package.el, then other packages from some other package manager, > then other packages from package.el. Why not just say it is the responsibility of the package manager to let the user say which packages it is to make available and which packages it is to leave for another package manager? That seems more flexible and natural to me. > dealing with autoloads Indeed, this seems like a big problem. Because a package can run arbitrary Lisp code in its autoloads, and the user expects this code to be run unconditionally when the package manager makes the package available (and in particular, *not* when a feature is required). If we have the package installed via two different package managers, then the only way to do this correctly seems to be to tell the package managers which one of them is supposed to activate the autoloads -- and then we are right back at the current situation. Would this require a restructuring of how autoloading works in general? If so, the resulting loss of backwards compatibility indicates that there need to be some concrete benefits to the new approach. ~~~~~ Another thing I worry about is whether this is the right abstraction for package managers that operate in different ways than package.el. For example, in the package manager straight.el, there is no concept of an "installed package". Instead, you specify to load a package declaratively in your init-file, and it is downloaded, built, and loaded automatically if necessary. One important point here is that the package is automatically rebuilt if it has changed since the last init, and the process of checking for modifications takes some time. If you care about your init-time, you probably would only want straight.el checking for modifications to packages that it actually loads (rather than ones loaded by a different package manager), so straight.el must be made directly aware of which packages it is actually supposed to load. Once again, this brings us back to the current situation. --001a114a6a52336f9305578571b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> The main benefit of such API would be interopera= bility between
> package managers.

So= to be clear, I like this proposal. But I'd like to ask whether it
will really offer a lot of benefit over the current situation.
<= div>Specifically:

> allowing for complex cases = like when you want some package from
> package.el, then other = packages from some other package manager,
> then other package= s from package.el.

Why not just say it is the resp= onsibility of the package manager to
let the user say which packa= ges it is to make available and which
packages it is to leave for= another package manager? That seems more
flexible and natural to= me.

> dealing with autoloads

Indeed, this seems like a big problem. Because a package can run
arbitrary Lisp code in its autoloads, and the user expects this cod= e
to be run unconditionally when the package manager makes the pa= ckage
available (and in particular, *not* when a feature is requi= red). If we
have the package installed via two different package = managers, then
the only way to do this correctly seems to be to t= ell the package
managers which one of them is supposed to activat= e the autoloads --
and then we are right back at the current situ= ation.

Would this require a restructuring of how a= utoloading works in
general? If so, the resulting loss of backwar= ds compatibility
indicates that there need to be some concrete be= nefits to the new
approach.

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 ~~~~~

Another thing I worry a= bout is whether this is the right abstraction
for package manager= s that operate in different ways than package.el.
For example, in= the package manager straight.el, there is no concept
of an "= ;installed package". Instead, you specify to load a package
= declaratively in your init-file, and it is downloaded, built, and
loaded automatically if necessary. One important point here is that
<= div>the package is automatically rebuilt if it has changed since the last
init, and the process of checking for modifications takes some tim= e.
If you care about your init-time, you probably would only want=
straight.el checking for modifications to packages that it actua= lly
loads (rather than ones loaded by a different package manager= ), so
straight.el must be made directly aware of which packages i= t is
actually supposed to load. Once again, this brings us back t= o the
current situation.

--001a114a6a52336f9305578571b7--