You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An idea I've been toying with, and wanted to start getting something more concrete designed, is to have PIE keep a record of which extensions it has installed. Maybe something like a $HOME/.config/pie/extensions.json or similar, with contents:
Discussed with Composer folks, it may be possible to use InstalledFilesystemRepository from Composer to track this. Should be possible to add the extra metadata that PIE needs (such as .so/.dll hash, configure options, target platform, etc.) in setExtra or setTransportOptions ("I'd recommend the latter as it's less likely to interfere but if you namespace it properly extra will be fine too I guess"). Something worth looking into to avoid re-inventing the wheel 💯
An idea I've been toying with, and wanted to start getting something more concrete designed, is to have PIE keep a record of which extensions it has installed. Maybe something like a
$HOME/.config/pie/extensions.json
or similar, with contents:overview
Essentially, each time PIE is used to install an extension, we record all the metadata/information about the installation.
What can this benefit?
See #24 - if an extension was installed with PIE, we know how it was built, so we can fairly simply rebuild it with the same configure options etc.
It may help with #13 too ?
Could also help with a generic
pie update
command, which tries to update all PIE-enabled extensions (with the help of the install log)When we do
pie show
, we can check thechecksum
against the real ext, to ensure it has changed (i.e. "it got out of sync with PIE").Note
ini-file-used
is allnull
at the moment, it is for future use when php/pie#20 is done.The text was updated successfully, but these errors were encountered: