From: Hugo Thunnissen <devel@hugot.nl>
To: sbaugh@catern.com, emacs-devel@gnu.org
Subject: Re: Preferred approach to inclusion of data in ELPA package
Date: Sun, 20 Aug 2023 19:47:18 +0200 [thread overview]
Message-ID: <c5874f2e-4db3-2393-a096-d4bad0d8a192@hugot.nl> (raw)
In-Reply-To: <87r0nxq1s3.fsf@catern.com>
On 8/20/23 15:30, sbaugh@catern.com wrote:
> Hugo Thunnissen<devel@hugot.nl> 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.
next prev parent reply other threads:[~2023-08-20 17:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 13:58 Preferred approach to inclusion of data in ELPA package Hugo Thunnissen
2023-08-17 21:14 ` Philip Kaludercic
2023-08-19 11:26 ` Hugo Thunnissen
2023-08-19 15:51 ` Philip Kaludercic
2023-08-20 19:24 ` Hugo Thunnissen
2023-08-20 20:42 ` Philip Kaludercic
2023-08-29 8:41 ` Hugo Thunnissen
2023-08-30 19:27 ` Philip Kaludercic
2023-08-20 13:30 ` sbaugh
2023-08-20 17:47 ` Hugo Thunnissen [this message]
2023-08-20 19:43 ` Hugo Thunnissen
2023-08-20 22:59 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c5874f2e-4db3-2393-a096-d4bad0d8a192@hugot.nl \
--to=devel@hugot.nl \
--cc=emacs-devel@gnu.org \
--cc=sbaugh@catern.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.