From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Bj=C3=B6rn?= Bidar Newsgroups: gmane.emacs.devel Subject: Re: feature/package-vc has been merged Date: Wed, 09 Nov 2022 22:16:23 +0200 Message-ID: <87pmdvsx2g.fsf@thaodan.de> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <838rkp4ptj.fsf@gnu.org> <87zgd58i7y.fsf@posteo.net> <83k0492u5i.fsf@gnu.org> <87fsew8g18.fsf@posteo.net> <83mt941cyd.fsf@gnu.org> <87fsewp0ec.fsf@posteo.net> <837d0814c9.fsf@gnu.org> <878rkooz1o.fsf@posteo.net> <831qqg1306.fsf@gnu.org> <874jvcowzm.fsf@posteo.net> <83y1soypvx.fsf@gnu.org> <87y1song5x.fsf@posteo.net> <83v8nsyof7.fsf@gnu.org> <87leoond7l.fsf@posteo.net> <87mt90tyns.fsf@thaodan.de> <87o7tgfw4m.fsf@posteo.net> <87eductx0x.fsf@thaodan.de> <871qqcfs9y.fsf@posteo.net> <875yfotn63.fsf@thaodan.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12848"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Philip Kaludercic , Eli Zaretskii , rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 10 07:29:50 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ot14O-000378-Qa for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Nov 2022 07:29:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ot10d-0002Ld-0g; Thu, 10 Nov 2022 01:25:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osrUq-0003zG-W8 for emacs-devel@gnu.org; Wed, 09 Nov 2022 15:16:29 -0500 Original-Received: from thaodan.de ([2a03:4000:4f:f15::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osrUp-0002qv-DK; Wed, 09 Nov 2022 15:16:28 -0500 Original-Received: from odin (dsl-trebng12-b04885-76.dhcp.inet.fi [176.72.133.76]) by thaodan.de (Postfix) with ESMTPSA id A29EBD08D4C; Wed, 9 Nov 2022 22:16:23 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail; t=1668024983; bh=E+iEy47ESmp1R7bMb3/rsP0X+2sSXR1I3mYZlrRJHLk=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=z/4BZ1x71chZmqVZPUSuOatwftyVUoMZWgTkH24zMHvEq2Bw9LY2Fdyn2NqI5bFqV J8zVCFny5wpCxH5+rFpKvGRkQ6cJOP3NaZCt9cuCjTgsf6DbtfEEFhMf2PFx6UGh0G 8CPx9Iw3uhd4k5vR6kNC8NAHU3i3VkXc1J73Spm2MesjlYutwYF1rJqub6NyV1lFvv 9BsN2paHIa1A5SR8iij6rnRIlxfq7eQNv/BEXPUyRFsa8sv/VNoFxq/zQJbOZ1V0fz 4pX0bXs7HADSjlFy0yMaJtmFnkXiiSkQ5riIcvdh+Q4+GHXdFAY21WFGJP9jdjHgC2 hkZ7wIsshVnlDq3A8vLC/wIrL+qc14lqJumE1ZN4DppWzmdliX6MXaYdM3W/TptlH6 ZKKzZV4yZF6VQ0Wy6MtuMm4OlgoVPFfoK9AH4rU9kECHrOS6KJuVN9YA+WuEC7pXNz zPYrm4jwQGiURMy7IiZWOd3rPJkywWyoQrVwDFEKTLFPOZbHAKA4py/omZWDr4xJXQ OiEgonRM/0SAbTYHASK0T0SgZ00PLAZAUNlaFfFOpcuSVd/nYNB5/8oLi1Z/WQPcB4 1SwOdaGS/RYTQ9DlypGjdXIr+RVtkcCHOq3hsIzlDwhyNq+ez7/us9Q+7nct7NClhI 4Xe7sCdY7wU1hR2YYeHNilfA= In-Reply-To: (Stefan Monnier's message of "Wed, 09 Nov 2022 12:41:07 -0500") Received-SPF: pass client-ip=2a03:4000:4f:f15::1; envelope-from=bjorn.bidar@thaodan.de; helo=thaodan.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 10 Nov 2022 01:25:51 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299457 Archived-At: Stefan Monnier writes: >>>> I noticed recently that some external packages such as projectile where >>>> copied but not to the extend or why that they are useful. >>> I am afraid I don't understand the issue you are describing. Could you >>> be more concrete? >> The package is copied but not as good because in the end it misses some >> features, it doesn't feel as polished. I don't have a direct example >> except missing features like no build system integration. >> It is just to bare bone. > > I don't know what you mean by "The package is copied". Then when you > say "not as good": as good as what? Same for "as polished": as polished > as what? > > I'm also not sure even what you mean by "the package": are you talking > about the tarball for `projectile` on NonGNU ELPA? > >> First of all I Didn't know about these elpa-packages but there are two >> cases where I think custom commands could be needed such as packages >> with native modules or some that require bootstrapping their build >> system by means such as autotools. > > All the packages I have found which used autotools were easy to convert > to rely on the normal build process for ELPA packages. > > For those packages which require building other artifacts, such as > `pdf-tools` or `libpq`, the current build recipe does not support that > at all because it was designed for elpa.gnu.org where we don't > distribute binaries compiled for specific architectures. > So instead, the build needs to happen during `package-install` and that > depends on the ELPA protocol which does not include any special support > for that :-( > Luckily it can be solved by appropriate ELisp code in the package, which > can trigger compilation of the artifact either during `package-install` > or later when the package is actually used. > It's not ideal, admittedly, but given the requirement to have something > that can work across various packaging systems (`package-install`, > `package-vc-install`, and possibly others), it's not that bad. The side effect of that process is that there's no standartized way for these packages to require native modules is that building those packages in build systems isn't standartized, these packages have to be convinced to not build binaries while Emacs run but take the prebuild binaries from the package manager. For packages provided by the package manager or which live for other reasons in /usr there no separate path for native packages/modules. Unless a separate load path is added manually they are not found in /usr/li= b. > I'm hoping that we'll develop a "standard" way to do it in the form of > some ELisp function/macro so that `pdf-tools`, `libpq`, etc... can > simply include a line or two of ELisp code which says how to compile > their artifact (possibly just running `make`, or `ninja`, ...). I'm not sure if that is always the best solution, maybe Melpa isn't the best place such packages. But just don't run them inside Emacs itself and not synchronously. Br, Bj=C3=B6rn