From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Hugo Thunnissen Newsgroups: gmane.emacs.devel Subject: Re: Preferred approach to inclusion of data in ELPA package Date: Sun, 20 Aug 2023 19:47:18 +0200 Message-ID: References: <28956ffc-6cc0-1f39-a26b-1453b48d61b1@hugot.nl> <87r0nxq1s3.fsf@catern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17322"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 To: sbaugh@catern.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 20 19:48:39 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 1qXmXW-0004Fl-Vg for ged-emacs-devel@m.gmane-mx.org; Sun, 20 Aug 2023 19:48:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXmWj-00027x-CU; Sun, 20 Aug 2023 13:47:49 -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 1qXmWg-00027i-2f for emacs-devel@gnu.org; Sun, 20 Aug 2023 13:47:46 -0400 Original-Received: from mailtransmit05.runbox.com ([2a0c:5a00:149::26]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXmWc-0007LF-TP for emacs-devel@gnu.org; Sun, 20 Aug 2023 13:47:45 -0400 Original-Received: from mailtransmit03.runbox ([10.9.9.163] helo=aibo.runbox.com) by mailtransmit05.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1qXmWW-00Ckug-3E for emacs-devel@gnu.org; Sun, 20 Aug 2023 19:47:36 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hugot.nl; s=selector2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References :To:Subject:From:MIME-Version:Date:Message-ID; bh=+F6RZQrZUVHQgu/eIUlltoEHXKIt5JocyPkpgzE848o=; b=TuaRLnPwOeJD7lxzvmTD8448PM PwTAXYVUGGRKu3HbJRgl0iLmmpVWelvBOUeWHYUAkbdu+aYneniH5+xNuuZGu+YijZ5OEboU3PtvC 9J/n1C142dGgmUmZwjCY5mLWfJxOXmgslMg35lXJcHo+bMAVz4XhjtsQIJA/N1dOU4DU85BKU++ba 2KJFrs69/xTL/aR92l9eiZpZ43ogEKe/vmydu6S0sb0e0gEbaL+grqp55F1k8Cw4pbUl4jiblKX0r b4yq+LFT+ntzLJz3ptCMCOxctWKVKiGHbA/TWBWrATwleI9AqGsfjJ1xo20Cm3U8mJ1SarDgWTaZ0 TPh+mn2A==; Original-Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1qXmWV-0000dC-Jl; Sun, 20 Aug 2023 19:47:35 +0200 Original-Received: by submission01.runbox with esmtpsa [Authenticated ID (1060096)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1qXmWF-0007lm-R9; Sun, 20 Aug 2023 19:47:19 +0200 Content-Language: en-US In-Reply-To: <87r0nxq1s3.fsf@catern.com> Received-SPF: pass client-ip=2a0c:5a00:149::26; envelope-from=devel@hugot.nl; helo=mailtransmit05.runbox.com X-Spam_score_int: -70 X-Spam_score: -7.1 X-Spam_bar: ------- X-Spam_report: (-7.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, NICE_REPLY_A=-4.279, RCVD_IN_DNSWL_LOW=-0.7, 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:308979 Archived-At: On 8/20/23 15:30, sbaugh@catern.com wrote: > 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. It is, but I think providing stubs for the latest stable version is acceptable. PHP is backwards compatible to a very high degree, so even stubs sourced from a different PHP version than their own will be useful for people. > 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. > I want to avoid directly executing PHP in an automated fashion, as phpinspect currently does not in any way depend on PHP. And with good reason. It is not uncommon for people to run PHP: - In containers - In virtual machines (there's a variety of ready-to-go "LAMP/XAMPP" virtual machine environments for example) - on remote systems with network mounted filesystems (nothing like going live the minute you hit save amirite? ;)) - Maybe, in a future where I get it working: via TRAMP That being said, there is room for improvement. One option I'm considering is to make it straightforward for users to generate/add their own stubs. This is probably a good idea regardless, as even if the user's PHP version matches that of the PHP installation that the stubs were sourced from, some users may be using lesser known/non-standard php extensions and may want to add stubs for them. Generating the stubs is quite straightforward, so most of the work would be to wrap this process in a nice UI within Emacs. Preferrably one that allows the management of multiple different sets of stubs. To give an idea of the process, this is a section of the current Makefile: ``` ./stubs/builtins.php: ./scripts/generate-builtin-stubs.php     mkdir -p ./stubs/     php ./scripts/generate-builtin-stubs.php > ./stubs/builtins.php ./data/builtin-stubs-index.eld.gz: ./stubs/builtins.php | ./.deps     mkdir -p ./data/     $(RUN_EMACS) -l phpinspect-cache -f phpinspect-dump-stub-index ``` In an ideal world, this feature should probably be paired with the ability to configure/detect the PHP version and extensions that a project requires. Projects that use composer usually state this in their composer.json file, but I'd have to decide whether I want to make composer a hard requirement for this feature or not. Another possibility is to add support for PHPStorm's stubs (https://github.com/JetBrains/phpstorm-stub). Their solution has been to generate stubs for every version of PHP + lots of extensions and distribute them with their IDE (see git branches for every version). I think this is a little overkill of a solution though. And I don't like the idea of users having to download all of these stubs from somewhere just to make this feature of the package functional. Also, would the apache2 license of these stubs cause any licensing problems? I imagine it would be fine if the stubs are not distributed with the package, but IANAL. I'm open to discussing better solutions and/or implementing them in the future. I'm currently working towards a first public ELPA release, so I might save large/complex improvements for a version after the first release.