New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of PECL Extension Installer #7970

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
5 participants
@torinaki
Copy link

torinaki commented Feb 11, 2019

Introduction

There were multiples PRs which were tried to address PECL extension installations:

  1. https://github.com/composer/composer/pull/498/files
  2. https://github.com/composer/composer/pull/2898/files
  3. https://github.com/composer/composer/pull/3897/files

Now the situation is slightly different. The PEAR which includes PECL command code contains multiple PHP 8 compatibility issues:

  1. pear/pear-core#82
  2. pear/pear-core#85
  3. pear/Console_Getopt#3
  4. ... and others

There is also an initiative to disable PEAR by default:

  1. https://externals.io/message/103977
  2. php/php-src#3781

IMO the effort to support PECL in the long term will be more significant then reuse Composer code base with existing functionality. So I'm trying to to find a solution to replace PECL command with a same or similar convenient way for PHP developers to compile and install extensions.

Scope

Note! Scope is topic of discussion, and it might be changed. It also depends on the required effort to implement the Extension Installer. So feature list might be cut to deliver a base implementation of Extension Installer faster.

  1. Reuse PEAR repository REST API client to communicate with PECL repositories.
  2. Implement possibility to download PECL extensions source using existing Composer functionality
  3. Implement extension compilation using phpize and make commands
  4. Implement installation of a compiled extension
  5. Download existing binaries and install extensions for Windows
@Seldaek

This comment has been minimized.

Copy link
Member

Seldaek commented Feb 11, 2019

If you want to look into this, please rebase on the 2.0 branch, as this will definitely not make it into 1.x.

The other considerations are that windows support is indeed a must have, and then the main question is.. does this make any sense at all considering that extensions can only really be installed/updated but not removed (as another project on the same system might still depend on them). It introduces a very special concept to Composer but if it can be done smoothly maybe it's worth it.

@nikic

This comment has been minimized.

Copy link

nikic commented Feb 11, 2019

I think some kind of extension installation functionality would be very valuable to have in composer, so that ordinary users (i.e. everyone minus extension maintainers) do not need to use PECL.

However, as the library and extension installation mechanisms differ a lot, I think it might be best (or at least to start with) limit this functionality to global installations. I.e. support composer global require pecl/apcu, but don't try to auto-install extensions from composer.json (or maybe only suggest that the possibility of doing a global installation exists, if an extension is missing).

@Seldaek

This comment has been minimized.

Copy link
Member

Seldaek commented Feb 11, 2019

Yeah... that was kinda the point/goal of https://github.com/FriendsOfPHP/pickle tho. I'd rather have the efforts focused there tbh, because if we want to support all various linux distros, package managers, windows and various strains of OSX PHP-installers, it gets real messy real quick. And I don't really feel like maintaining all of this within the Composer project.

The ideal situation would have a pickle binary that works well, that users can use, and that Composer can suggest using in case extensions are missing, or maybe we can even execute it directly if available in $PATH..

I don't know what the state of the code is in Pickle, but I suspect it's at least more modern as pecl/pear, and probably worth reusing bits of it rather than starting fresh. /cc @pierrejoye @weltling @jubianchi @Hywan

@pierrejoye

This comment has been minimized.

Copy link

pierrejoye commented Feb 12, 2019

@pierrejoye

This comment has been minimized.

Copy link

pierrejoye commented Feb 12, 2019

Also looking at this PR, it is missing a lot of things, I wished it would be so easy :). I would relatively strongly suggest to see what is done in pickle and what features are needed. Ideally we could work on creating a PR for composer. However I would like to have clear details about how it should be done or how composer likes to have it. :)

@nikic

This comment has been minimized.

Copy link

nikic commented Feb 12, 2019

@pierrejoye Can you provide some information of what the current state of pickle is? Personally I don't think composer integration is even the important part here, what we need first and foremost is a reasonably modern replacement for pecl install. Is pickle ready for that? If yes, why is not widely used right now? If no, what is still missing?

@Seldaek

This comment has been minimized.

Copy link
Member

Seldaek commented Feb 12, 2019

I agree that composer integration should come later, once a given tool is proven suitable for the task.

@pierrejoye

This comment has been minimized.

Copy link

pierrejoye commented Feb 12, 2019

@nikic yes it is. It supports pecl.php.net, github or technically composer's packagist if necessary. Builds from sources (github, local, zip or tgz) on linux and windows (did not try mac but should work as it is gcc+autoconf), with configure options or binary install (windows, from our builds).

@Seldaek and I discussed about using packagist for extensions, I did a pickleweb concept but ideally we should use packagist and only add what is needed for extensions (basically more meta).

Not widely used because not wild promotion :) I also lacked the time to really follow up on it, but everything is there and working. I can do a health check with latest PHP versions (incl. master if desired).

@pierrejoye

This comment has been minimized.

Copy link

pierrejoye commented Feb 12, 2019

@Hywan

This comment has been minimized.

Copy link
Contributor

Hywan commented Feb 12, 2019

We can double down on Pickle if you want to integrate it. That will increase the adoption greatly.

@torinaki

This comment has been minimized.

Copy link
Author

torinaki commented Feb 14, 2019

@Seldaek, @nikic, @pierrejoye according to your discussion I came up with a conclusion that the easiest way is to actualize the Pickle repository.

Probably it is essential to make Pickle work before PHP 8 will be released and test on currently supported PHP versions starting from 7.1.

I think that in the context of FFI, Preloading, and JIT RFCs we are going to direction when PHP might have something similar to Python's Wheels packages where we can have PHP and C extension code in a single repo (or at least will have a dependency on both). Obvious it would not happen soon if even happen at all.

P.S. I create PR ahead of working and complete implementation to raise the discussion to avoid wasting time on changes that would not be accepted by the community.

@torinaki torinaki closed this Feb 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment