From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: sbaugh@catern.com Newsgroups: gmane.emacs.devel Subject: Re: Preferred approach to inclusion of data in ELPA package Date: Sun, 20 Aug 2023 09:30:36 -0400 Message-ID: <87r0nxq1s3.fsf@catern.com> References: <28956ffc-6cc0-1f39-a26b-1453b48d61b1@hugot.nl> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17941"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:Iezafqzn/X+vBAWieSf5JxBO1vQ= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 20 17:16:36 2023 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 1qXkAO-0004SW-7m for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Aug 2023 17:16:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXk9j-0006Jh-EM; Sun, 20 Aug 2023 11:15:55 -0400 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 1qXiW6-0006FW-GC for emacs-devel@gnu.org; Sun, 20 Aug 2023 09:31:02 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXiW3-0004su-US for emacs-devel@gnu.org; Sun, 20 Aug 2023 09:30:53 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qXiVu-0009mi-5Q for emacs-devel@gnu.org; Sun, 20 Aug 2023 15:30:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 20 Aug 2023 11:15:36 -0400 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:308964 Archived-At: Hugo Thunnissen writes: > Hi all, > > For my package phpinspect.el I am now looking into the creation of an > index of PHP's built in functions and classes. I'm considering > different ways of distributing this dataset, but I'm not entirely sure > what would be the preferred way. Finding out the signatures/properties > of built in functions and classes is straightforward: I can generate > valid PHP stubs for them which can then be parsed an indexed by my > package just like any other PHP code. Isn't this data dependent on the version of PHP that the user is using phpinspect.el with? So distributing a single canonical "set of stubs" would be inaccurate. Is it possible to automatically generate even the set of stubs on the user's computer, by running PHP? Doing that operation on the user's computer, and caching the output so that subsequent loads are fast, seems like the best option to me. Then you completely avoid this problem of distributing data, and you also get behavior which reflects the version of PHP the user is working with.