Composer Requirements

[perftools]

Composer Requirements

[markstory]

@lauripiisang Would you be interested in moving that repository to this org? You could continue to maintain the collector, and we could work together to slim down this project to not contain the collector code.

[preinheimer]

So that's a dead easy way to solve the problem short term.

I think a bigger question is: Should we split the data collector and UI into separate projects. The former requires xhprof, the latter doesn't. The latter requires mongo, the former doesn't.

[kuncajs]

Well from architectonic point of view that would be an ideal solution to divide it into "data collector" and "plain GUI", the question is how many users want or need this kind of functionality.

But IMO: I think that not many PHP projects use MongoDB on the live environment and make this memory consumer running all the time "just for profiling" is not ideal way. Also on some environments you might not be able to run your own Mongo and data collector just needs xhprof. We want to put the files in the directory and make CRON scp them and import using the tool your project contains automatically. And on your local where you can display all the info you need you are able to run whatever you wish. So I will never use the GUI on server and I will never use the xhprof on my local...

So for me the split would be perfect but only in case that people need it ( I do :-) )

[markstory]

I think a split might work well. If we add more libraries to xhgui, I'd like a way to not bog down the host application with those dependencies.

One tricky bit with splitting the project up into a collector and UI, is how to manage configuration?

[preinheimer]

Hrm.

The collector needs xhprof, and the display needs mongo. How granular can we get with composer? Like could we mark them both as required and somehow tag things as non-functional if they're not there? So they'd install the same package twice, but get clear indication regarding functionality?

[markstory]

composer will require separate repos for each package. It doesn't have a way of making multiple packages out of one repository.

[kuncajs]

Still you can make it as THREE packages (repos)

1. Collector
2. GUI
3. remains like this one but does not have almost any code and only declares these two as a requirement so people can go on with using that as they were used to

[markstory]

Another option is to do what symfony and laravel do, and automate some subtree splits. I don't know how having the gui as a separate package will work for people as the webroot directory will move around, as will cache & config files.

[preinheimer]

What if we had one package/repo, then marked both XHProf and MongoDB as optional. Then just appropriately tagged the components (data collector/presenter) as non-functional without the various elements.

[markstory]

Thats a reasonable option I think.

[pavelsmolka]

Hi,

It was possible to install xhgui as a dependency without having ext-mongo installed for quite a long time. However, in commit c3a3f43, a new dependency has been added:

c3a3f43#diff-b5d0ee8c97c7abd7e3fa29b9a27d1780R17

I am not sure what the reason for adding the dependency was. I can't see anything from the commit itself. It'd be great if we can maintain xhgui as a data-capture tool, as suggested earlier in this thread, and separate the data-display logic. I guess I am not the only guy who wants to run xhgui-based profiling on the production machines, while not having ext-mongo installed there.

[markstory]

@pavelsmolka I can move that dependency into suggest. Splitting xhgui up might be an option in the future. I don't have a ton of time to do that right now though.

[pavelsmolka]

Hi, I have created a pull request, with simply moving the Mongo dependency to the "suggest" section of composer.json. I have briefly checked the code, and I'm not sure whether some more changes need to be introduced for this MR to be accepted. I'm happy to put a bit more work into this, if you guide me into the right direction.

[lauripiisang]

Digging up graves, but FWIW, as @kuncajs proposed, I have extracted the minimal amount of code needed to provide a data collector from XHGUI project.
This is version-agnostic, should work on PHP 5.3 - 7.1 and doesn't modify (aside from deleting) the original code.

see https://github.com/lauripiisang/xhgui-data-collector
There's a version up on packagist as well.

Got scrutinizer rank up to 10.0 :)

[lauripiisang]

@markstory I don't see why not. the current project is just a very basic teardown of the unnecessaries with compatibility in mind, but I'd love for it to evolve into something more.

How do we go about doing that?

P.S. on a different topic - please create tagged releases of xhgui project on packagist!

[markstory]

P.S. on a different topic - please create tagged releases of xhgui project on packagist!

There has been a recent change to remove the version key in the composer.json that should fix tags not getting picked up going forward. There doesn't seem to be a way to backfill existing tags into packagist though.

[lauripiisang]

Clicking "update" in the project view should refresh all references

…

On Apr 5, 2017 19:06, "Mark Story" ***@***.***> wrote: P.S. on a different topic - please create tagged releases of xhgui project on packagist! There has been a recent change to remove the version key in the composer.json that should fix tags not getting picked up going forward. There doesn't seem to be a way to backfill existing tags into packagist though. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#85 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFWAyUFHLOVRYUigD26pK53UL9AiT16zks5rs7wXgaJpZM4BZ6Mj> .

[markstory]

It doesn't. I pushed that button a few times last night 😢. Could packagist not be finding the tags because the old tags are prefixed with v?

[glensc]

packagist tag problem solved: #199 (comment)

[lauripiisang]

I've pushed lauripiisang/xhgui-data-collector to perftools/xhgui-collector, but there are some issues to resolve:
perftools/xhgui-collector#1

[Krinkle]

It looks like perftools/xhgui should at least depend on perftools/xhgui-collector. Rather than the code being duplicated. This would also keep perftools/xhgui backwards compatible with existing usage. The main concern is that the collector used in production is minimal.

[glensc]

common parts should be moved to separate library instead. this was also @lauripiisang opinion.

but this is likely not worked on (beside lack of time/interest/profit) because it would be major breakage for people who do not use composer for xhgui installation. currently it's standalone, no external (composer) dependencies.

this could be solved two ways:

• introduce major version, which requires composer
• upload tarballs to releases which contain dependencies (result of composer install --no-dev)

[markstory]

I think requiring composer might be an option now. Back when this project started, I don't think composer was as widely used as it is today. Making tarballs for releases isn't that hard either. I have some make scripts to do just that from automating releases in CakePHP.

[lauripiisang]

We could have some plans for major version then in general, like PSR-4 compatibility and perhaps some restructuring, better error handling.

WDYT?

Perhaps we should consolidate these under an issue.

[markstory]

We could have some plans for major version then in general, like PSR-4 compatibility and perhaps some restructuring, better error handling.
Perhaps we should consolidate these under an issue.

Sounds like a plan. I think there are a bunch of things we can and should improve.

[glensc]

perftools/xhgui-collector has been created, which is now superseded by perftools/php-profiler package.