Skip to content
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

draft support for Pickle in Composer #3897

Open
wants to merge 18 commits into
base: main
Choose a base branch
from

Conversation

pierrejoye
Copy link

Draft support for Pickle (https://github.com/FriendsOfPHP/pickle) in Composer.

Spent more time to dig composer code than actually implement that but at least it works to install exts from within a project.

Example project and extension composer.json:
https://gist.github.com/pierrejoye/1bbc2bdcec5887e60490

If you like to test with more extensions:
git clone myext
cd myext
pickle convert

Add the dep to your project. If you do not want to fork an ext, you can create a dep vs a zip file and use the artifact repository, it should work.

Still many things to solve but at least there is something to play with now

Update:

According to our discussions, it is now a two steps process to install extensions, to make sure users understand that installing extensions may affect many projects:

First, the usual command:
composer install

composer will tell you to run
composer install --install-extensions

if the project has extensions dependencies

@@ -345,7 +345,6 @@ private function findFileWithExtension($class, $ext)
{
// PSR-4 lookup
$logicalPathPsr4 = strtr($class, '\\', DIRECTORY_SEPARATOR) . $ext;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be reverted

@pierrejoye
Copy link
Author

Made most of the changes you pointed at, except the tmp dir one and the zip downloader

@naderman
Copy link
Member

naderman commented Apr 1, 2015

I'm really not sure this is a good idea. We discussed in #2898 (comment) why having an ExtensionInstaller is a bad idea, and outlined how this should be implemented instead.

The ExtensionInstaller installs dependencies globally which is very different from how the rest of composer behaves. It does not follow the per-project behavior of composer. If you use the ExtensionInstaller in one project it impacts all other projects on the same machine too, but you will never be informed that you broke the dependencies of the other projects. This needs to be handled much more explicitly and transparent for the user, as is outlined in the comment I linked to.

@pierrejoye
Copy link
Author

@naderman huh.
We discussed that intensively and you agreed on that. Composer integration was a must have. And one of the ground reason why I started pickle in the 1st place.

Also keeping in mind that multiple php support is coming. That and FPM Pool allows easy per project extensions managements, or fcgi on windows.

So what do you suggest now?

@naderman
Copy link
Member

naderman commented Apr 1, 2015

Yes I do want it to be integrated, just in the way outlined in that other PR, not as an extension installer.

protected $pickle = 'pickle';
protected $process;
/**
* Initializes library installer.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not the library installer

@pierrejoye
Copy link
Author

@naderman Ok, after discussions on IRC, makes sense for now. I will try to post a summary :)

Will update the patch accordingly, this PR was a draft to start this exact discussion, so no worry. I am not sure where to start to skip extension during install step 1 and skip non extension during install step 2, somehow an ExtensionInstaller is still required, but do not have to be called if '--install-extensions' is not used. Or?

@stof
Copy link
Contributor

stof commented Apr 14, 2015

how are available extensions known by Composer ? Does pecl.php.net support the Composer protocol to expose packages ? Does it require a special repository implementation ? Or does it need to wait for pickle-web ?

@pierrejoye
Copy link
Author

No, it won't. Or I don't see why composer should do it. Mind to enlighten
me?
On Apr 15, 2015 5:41 AM, "Christophe Coevoet" [email protected]
wrote:

@pierrejoye https://github.com/pierrejoye the issue is that it would
force Composer to hardcode a list of extensions provided by the core (and
it could still be wrong in case of package managers bundling them
separately, even though they might use strict deps to prevent this). It
would be better to have core extensions being updated to expose the PHP
version as their own version too.


Reply to this email directly or view it on GitHub
#3897 (comment).

@pierrejoye
Copy link
Author

@stof yes, see http://news.php.net/php.internals/85814

and we need a list anyway. Which one is bundled in which major version. They have to be handled differently.

@pierrejoye
Copy link
Author

Also it is not composer's job to keep that list nor to deal with but pickle, composer does nothing about extensions but check if they are loaded.

@sbuzonas
Copy link
Contributor

How far off would a PECL repository be from the PEAR repository?

@pierrejoye
Copy link
Author

@slbmeh I do not get the question but let me try to answer based on a guess :)

Pickle does not use pear, at all. It does not need package.xml but can handle package with only package.xml but no composer.json (live conversion).

@pierrejoye
Copy link
Author

Also, I would love feedback about the patch (not CS pls, I will fix them) and if it is how you like to have it.

I can go with a plugin instead for the meantime, as this is a blocker for now.

@sbuzonas
Copy link
Contributor

@pierrejoye sorry I had the context in my head. That was a question building off of @stof's question about discovering extensions in regards to a special repository. I believe the PECL and PEAR repositories are rather similar and may be able to work with the existing PEAR stuff.


protected function createTempDir()
{
$lockfile = tempnam($this->cacheDir, 'pickle');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this create a file every time you generate a new directory name?

@pierrejoye
Copy link
Author

@slbmeh please check what Pickle is, it could be a good start.

And no, we are not going to use pear for that, that's exactly the goal, to do not use pear anymore as it is a pain to use as an extension developer.

@sbuzonas
Copy link
Contributor

@pierrejoye I'm aware of Pickle. I'm not suggesting anything about Pickle itself. I thought the question was about how will composer know about extensions. My reference to pear was about https://github.com/composer/composer/blob/master/src/Composer/Repository/PearRepository.php, I don't think it's too far of a stretch to make that work with pecl.php.net so you don't have to duplicate metadata.

@stof
Copy link
Contributor

stof commented Apr 16, 2015

@pierrejoye the PlatformRepository providing the info about the platform itself needs to be able to know the version of installed extensions, otherwise you cannot use the version in the constraint.
so if PHP extensions don't expose their version properly, we would have to add such knowledge in Composer itself to reuse the PHP version

@stof
Copy link
Contributor

stof commented Apr 16, 2015

@slbmeh the PearRepository is a huge performance killer, because the PEAR protocol is just not adapter for Composer needs, required a huge number of requests to fetch the necessary data.
This is why Pirum introduced first-class composer support for the pear repositories it generates, to avoid having to use the PearRepository with them.
If we want to make extensions installable with Composer, the extension registry should expose its metadata in an efficient format for Composer (the best idea being to use the composer protocol, used by Packagist and Satis, as this means that Composer already has the support for loading the metadata without doing another implementation).

@pierrejoye
Copy link
Author

OK, sorry but still no :)

pecl is by far not the place anymore where ppl releases their extensions.
That is why we need pickle.

And pickleweb (packagist for extensions) instead. Bringing the simplicity
of composer to ext developers when it comes to releases, and a good ext
index for the users.
On Apr 16, 2015 6:27 PM, "Steve Buzonas" [email protected] wrote:

@pierrejoye https://github.com/pierrejoye I'm aware of Pickle. I'm not
suggesting anything about Pickle itself. I thought the question was about
how will composer know about extensions. My reference to pear was about
https://github.com/composer/composer/blob/master/src/Composer/Repository/PearRepository.php,
I don't think it's too far of a stretch to make that work with
pecl.php.net so you don't have to duplicate metadata.


Reply to this email directly or view it on GitHub
#3897 (comment).

@pierrejoye
Copy link
Author

@slbmeh pickle works with pecl.php.net transparently and out of th box, even if a release has no composer.json.

Same for the web hooks on registration or release tag.

@stof pickle ensures that the version is set correctly. It cannot be released if not. I also started a discussion on internals to fix the core extensions versions.

@pierrejoye
Copy link
Author

@stof Will look at the PlaformInfo part, it could be possible to get it to know the installed extensions. I have to check to do not duplicate the installed version management. Not sure how yet.

Waiting on @Seldaek and @naderman to comment on this patch, where it is done and how, then I will investigate further about these things.

@pierrejoye
Copy link
Author

A couple of things we support in pickle and not sure how to make them work smoothly when called from composer.

Old releases of an extension may not have composer.json (or will most not have), composer will fail on these release. What pickle does is to check for package(2).xml and convert on the fly to generate a usable composer.json. Absence of package.xml will be supported as well, composer.json being created from the src (README, header, etc). It is already partially done for the convert command.

Ideas for the composer part? Or we may simply require it when used from composer, that will help extensions developers to get to add composer.json.

@Seldaek
Copy link
Member

Seldaek commented Apr 30, 2015

Well composer doesn't really need the composer.json if the pickle repo provides the metadata. It is needed however if we want to load a github repo of an ext as a vcs repository in composer, so yes if people add it eventually it'd be great.

@pierrejoye
Copy link
Author

We will enforce it for any new release. But the question is for older
releases, they have none. If composer called pickle for every ext
dependency directly without checking anything, then it is easy.

If not, and the repo (source, VCS, whatever) does not have composer, it may
fail or I do not see how composer can get all the metas.

It also brings me back to the main point. What do you think about the draft
patch? Where it is hooked and so on? :/ about to open beta for the
pickleweb, would be great if we can get composer supporting it. If not, no
big deal but the gap will get bigger.
On Apr 30, 2015 3:52 PM, "Jordi Boggiano" [email protected] wrote:

Well composer doesn't really need the composer.json if the pickle repo
provides the metadata. It is needed however if we want to load a github
repo of an ext as a vcs repository in composer, so yes if people add it
eventually it'd be great.


Reply to this email directly or view it on GitHub
#3897 (comment).

if (!$this->installExtensions && $operation->getPackage()->getType() == 'extension') {
$this->io->writeError('<warning>This package has extensions dependencies, run composer install --install-extensons</warning>');
continue;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should maybe support 'update' operations too

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If an extension is loaded it cannot be updated. That's the tricky part. It
is also why we somehow need to be able to run pickle against a different
php than the one running pickle. Or use -n but then... :)
On May 5, 2015 5:11 PM, "Jordi Boggiano" [email protected] wrote:

In src/Composer/Installer.php
#3897 (comment):

@@ -523,6 +525,10 @@ protected function doInstall($localRepo, $installedRepo, $platformRepo, $aliases
foreach ($operations as $operation) {
// collect suggestions
if ('install' === $operation->getJobType()) {

  •            if (!$this->installExtensions && $operation->getPackage()->getType() ==  'extension') {
    
  •                $this->io->writeError('<warning>This package has extensions dependencies, run composer install --install-extensons</warning>');
    
  •                continue;
    
  •            }
    

Should maybe support 'update' operations too


Reply to this email directly or view it on GitHub
https://github.com/composer/composer/pull/3897/files#r29656783.

Copy link
Member

@Seldaek Seldaek May 5, 2015 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@flip111
Copy link

flip111 commented Mar 6, 2016

any news?

@Seldaek Seldaek added this to the Nice To Have milestone Apr 12, 2016
@gabrielrcouto
Copy link

@Seldaek Do you need any help to test and close this PR?

@naderman naderman mentioned this pull request Nov 28, 2020
4 tasks
@faizanakram99
Copy link

bump

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants