collaborate with other guzzle bundles?

[lsmith77]

https://github.com/search?q=Guzzle+Bundle&ref=searchresults&type=Repositories

would be great if there could be some work to collaborate and build one GuzzleBundle instead of the current long list.

/cc @zachbadgett @ddeboer @thewilkybarkid @ludofleury @xamado

[lsmith77]

xamado/guzzle-bundle#1
orkestra/OrkestraGuzzleBundle#61
#28
ddeboer/GuzzleBundle#21
ludofleury/GuzzleBundle#9

[ludofleury]

Yeah we already talked about the author of this (misd) repository, but since we had no news. I'm okay to merge with one, since my lil' bundle is focused on the web debug toolbar + profiler panel for Guzzle.

I don't provide anything else, the config is done manually or with a dic tag. The best deal could be to move one bundle behind the guzzle organization, we contacted @mtdowling by mail without success few months ago.

[mtdowling]

Sorry if I didn't respond. I think merging the good ideas from all of the different Guzzle bundles into a single bundle would be awesome. It sounds like merging @ludofleury's bundle and the @thewilkybarkid's bundle would be a good first step.

I am also in favor of forking one of these bundles to become the official GuzzleBundle (with current authors having commit access of course), but I'd want permission from the authors. I think that having an official Symfony Bundle under the Guzzle organization would definitely help to reduce confusion over which bundle to use and would help to ensure that at least one of the bundles is kept up to date.

[ludofleury]

@mtdowling @thewilkybarkid I'm okay with that.

[ddeboer]

It seems the MISD bundle surpasses the other bundles (including my own) in functionality and recent activity.

@ludofleury Would you be willing to submit your data collector as a PR to the MISD bundle? When that PR has been merged, @mtdowling can make this bundle the official one by forking it and registering it on Packagist as guzzle/guzzle-bundle.

[ludofleury]

Ok sure.

[ludofleury]

I'll just introduced the missing unit test to my bundle, It needs some refacto, I think I woul dbe able to submit PR asap. @thewilkybarkid could you please upgrade to support Symfony 2.3 ?

[mtdowling]

That's awesome!

On Jun 12, 2013, at 6:17 PM, Ludovic Fleury [email protected] wrote:

I'll just introduced the missing unit test to my bundle, It needs some refacto, I think I woul dbe able to submit PR asap. @thewilkybarkid

—
Reply to this email directly or view it on GitHub.

[thewilkybarkid]

Collaboration would be a good thing for everyone. 😃 I'm not sure that changing the namespace is that important though, in comparison to having a bundle that is actively maintained and developed (which I like to think this is!), and mentioned in the Guzzle docs (which this is since https://github.com/guzzle/guzzle-docs/pull/37). It would involve a lot of people updating their dependencies (I think it's around 1,000 installs a month according to Packagist, and is growing - not exactly Guzzle core levels, but not insiginificant), plus it's been licensed to my work so would need an ok from them.

If there were to be a Guzzle 4 at some point though, and assuming it's not BC, that would be a suitable time to make a new official bundle.

[lsmith77]

in terms of licensing this is handled by the MIT license. in terms of updating the namespaces. i think it would be quite trivial. for the most part it would be changing the composer.json, config.yml and AppKernel.php.

[thewilkybarkid]

Yes, but I mean everyone has to update their composer.json file. (There would need to be some other changes too, config, tags etc).

I don't see it as a problem not being in the Guzzle namespace, and I don't really see any benefits to moving it.

[lsmith77]

I think the biggest benefit of putting it into the Guzzle namespace is:

1. making it clear what the go to Bundle is for the future
2. ensuring long term maintenance via the community rather than individuals

Of course credits should remain visible with in the composer.json and README.md and of course also file headers.

[thewilkybarkid]

Both those things are important (this bundle was first created as there wasn't an existing that was being maintained), but I don't see having Guzzle on the tin as making much, if any, difference to either. (It is being, and will continue to be, maintained since we're using it in multiple production systems; and as an example of community maintenance the recent Guzzle 3.6 breaking changes quickly saw a load of PRs trying to fix them.)

[ludofleury]

Clearly agree with @lsmith77 and the move initiated, we already discussed that in december tho.

[seiffert]

👍 for moving it to the Guzzle namespace. I really like the functionality of MisdGuzzleBundle and I am thankful for the effort you put into it. However, I have bad feelings when using bundles that are maintained by a single person in customer projects. Also, becoming the the 'official' Guzzle bundle would be a real boost for your bundle's popularity, wouldn't it?

[ludofleury]

Hey, where are we going here ?

If you don't have time to PR, I can do it for you and manage the Guzzle organization transition. I really don't see any drawback of simply moving an super nice Open Source repository to the official organization:

• everybody in the open source community will benefits from this explicit clarity.
• contributors of the MISD would have to change the remote host url in their git config and would got more visibility.

Since it's @thewilkybarkid repository, it's your call.

[tecnocat]

Hi guys, thanks for your effort, Guzzle it's an amazing library.

The combining each powerful bundles in only one bundle is a fantastic idea!

THANKS!

[lunetics]

Any updates on this?

[zerrvox]

What happened to these plans? @thewilkybarkid

[Ninir]

Any news for this one? @lsmith77 @ludofleury @mtdowling

[ludofleury]

I'm late behind the review of the PR I made. I'll try to do something about that ASAP. It's mainly frontend optimizations concerns for the profiler panel. Feel free to help if you like to contribute.

[Ninir]

@ludofleury Sure! if you could make a small list of what needs to be done for you, would be glad to help and improve the overall if possible :)

[ludofleury]

All right, I just read about GuzzleHttp aka 4.*, what are your plans @thewilkybarkid ?
Should we let die this PR and focus our efforts on a common bundle for this new version ?

WDYT ? @mtdowling, @lsmith77, @Ninir, @ddeboer

[csarrazi]

I had actually started working on a 4.0 bundle, forking @ludofleury's bundle. Unfortunately, I'm not satisfied with the result yet, so I'm actually thinking to start anew.
If anyone wishes to contribute, feel free to let me know, so we can focus on a common bundle for 4.*

[ludofleury]

@csarrazi nice. No repo ?

[csarrazi]

Only locally. But as I'm not satisfied with it, I'm thinking about throwing the code.

[Ninir]

@csarrazi Would be cool, yep! :)
thanks!

[ludofleury]

@Ninir for the 3.* version, see the PR here: #29 There is some comments at the end about the frontend otpimization.

@csarrazi I'll try to port the profiler/datacollector for bundle 4.*, since the history plugin is available for GuzzleHttp, it seems doable. Did you face any prob ?

[csarrazi]

Not for integrating the client. It's quite alright. But the code has started to get a little too big in the data collector, in my opinion.

[thewilkybarkid]

If creating an "official" bundle is still considered important, then now is the time to do it (since it would have to be a new major version). If that does happen (and is done well/is well maintained), then there's no need for this bundle to look at handling Guzzle 4. I don't really agree with it (the stability
popularity/stability of this bundle over the others shows that there isn't a problem), but if it happens then there's no sense in competition.

If not, then a version 2 of this bundle is on the horizon.

[ludofleury]

@thewilkybarkid valid opinion. A bundle living under the Guzzle repository would be easier to find for new comers. So if you plan to upgrade yours, maybe we could ask @mtdowling if he stills okay for that.

[Ninir]

A new repo under the hood of Guzzle would be more appropriate, 👍 for this idea.

[csarrazi]

There you go!
I have just released my own bundle, handling GuzzleHttp 4.

https://github.com/csarrazi/CsaGuzzleBundle

Most of the functionality is already available. Of course, the timeline's display can be improved, as well as the listener to separate the different steps of the http calls (waiting, receiving response, etc.). It also needs a bunch of tests.

[ghost]

i don't get what happened here. what was the holdup?

[dinamic]

Guys, any update on how the merge is going? I was using https://github.com/LeaseWeb/LswGuzzleBundle, but it has a memory leak issue and is also using the 3.x version of guzzle.

I'm going to try using https://github.com/csarrazi/CsaGuzzleBundle.

Perhaps it would be a nice idea to have a repository created under the Guzzle organization, so the people can start to merge and build the new bundle that is to unite the existing code base. It will be nice to have different tags for version 3.x and version 4.x, as some people may still rely on the old one.

[csarrazi]

Guzzle 3 will soon be deprecated, as with many libraries that still rely on PHP 5.3 (composer minimum PHP version will slowly be increased to PHP 5.4+).

For people who still rely on PHP 5.3, they can still rely on the older bundles.

[ghost]

Please look at issue #90

[Tobion]

@lsmith77 IMO this issue can be closed. The many-bundle problem still persists but this place is the wrong repo to possibly discuss this as it is not maintained and only for Guzzle 3.

[Tobion]

@lsmith77 please close