From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: feature/package-vc has been merged Date: Wed, 09 Nov 2022 12:41:07 -0500 Message-ID: References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <87sfiyk3a2.fsf_-_@posteo.net> <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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34515"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Philip Kaludercic , Eli Zaretskii , rms@gnu.org, emacs-devel@gnu.org To: =?windows-1252?Q?Bj=F6rn?= Bidar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 09 18:42:02 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 1osp5O-0008jG-09 for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Nov 2022 18:42:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1osp4k-0004ab-EE; Wed, 09 Nov 2022 12:41:22 -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 1osp4g-0004a2-65 for emacs-devel@gnu.org; Wed, 09 Nov 2022 12:41:18 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osp4c-0002Q3-6q; Wed, 09 Nov 2022 12:41:17 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 226A880796; Wed, 9 Nov 2022 12:41:11 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8249880258; Wed, 9 Nov 2022 12:41:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1668015669; bh=p/CFYoUGCaqj1ciPWFIVGr10knacKTygjEhDdI8w6xs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LDo9XcluKCWxRxJwDQL4AhtniZfuetLPUaiU0yv1aAoAN0tE8BZLA5234ccAYpsPs Iz69P5Gvs+qb0yUyHqlrizLI8luIp0/9QhYYCbB8pJotgz2zviQOo2J2k386eNOngR H4yWem1512Jv+bj6d+V5qdsnVdaUHfog+jgd1GkmOt3YR4zEW8/m1gZVAiyxyQ17tt eTK1W62apMo9SK9b02BK2HGL5JIl+iGtQMtivqi4Z0ewkCcTaLOgjVJzjtQrC5FpzJ D+N68bbr4ZPUoBly21kVu+QvjSsUxqIfu271ya02MCmY8sQlGppxHLyzk72OCGqHXQ NDr9gdfbcHDfA== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 65F90120183; Wed, 9 Nov 2022 12:41:09 -0500 (EST) In-Reply-To: <875yfotn63.fsf@thaodan.de> (=?windows-1252?Q?=22Bj=F6rn?= Bidar"'s message of "Wed, 09 Nov 2022 12:52:36 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:299417 Archived-At: >>> 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. 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`, ...). Stefan