Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 23 2019 19:21
    Travis peter279k/url-generator (test_enhancement) passed (3)
  • Apr 23 2019 19:21
    Travis peter279k/url-generator (test_enhancement) passed (3)
  • Apr 23 2019 19:19
    Travis peter279k/url-generator (test_enhancement) passed (2)
  • Apr 23 2019 19:16
    Travis peter279k/url-generator@9f06b76 (test_enhancement) errored (1)
  • Nov 03 2018 22:00
    rejinka closed #5
  • Nov 02 2018 20:48
    tgalopin closed #43
  • May 17 2018 14:17
    XedinUnknown opened #209
  • May 17 2018 14:11
    XedinUnknown commented #100
  • Apr 05 2018 15:41
    JLepeltier commented #190
  • Jan 02 2018 20:28
    Nyholm commented #52
  • Dec 28 2017 23:36
    odhiambo123 commented #52
  • Dec 28 2017 23:35
    odhiambo123 commented #52
  • Dec 28 2017 23:33
    odhiambo123 commented #52
  • Dec 28 2017 22:50
    odhiambo123 commented #52
  • Dec 28 2017 07:26
    Nyholm commented #52
  • Dec 28 2017 07:00
    odhiambo123 commented #52
  • May 10 2017 00:10
    selvi94 commented #96
  • May 10 2017 00:07
    selvi94 synchronize #96
  • May 10 2017 00:02
    selvi94 commented #96
  • May 09 2017 23:57
    selvi94 opened #96
Tobias Nyholm
@Nyholm
Thank you for the reminder
=)
Théo FIDRY
@theofidry
actually I made a mistake, I putted 2pm for London not Paris...
Titouan Galopin
@tgalopin
Today, @theofidry @Nyholm and me had a hangout with Jordi Boggiano (seldaek, from Composer) to discuss the possibilities of creating a generic installer for phars and integrate it in composer
During this discussion, jordi expressed the fact that he is not willing to add such big features to Composer as he wants a stable probject
Instead, he proposed that we create a project and in the Composer documentation, he could add a paragraph about handling phar using our project
Titouan Galopin
@tgalopin
this discussion was also the opprtunity to ask what we should be careful of if we wants to create a real installer
after the discussion with jordi, we (puli guys) stayed a bit longer and discuss the options
theo proposed creating a composer plugin for puli specifically
as it would me much simpler than working on a real generic installer and it could be done quite quickly
we have to debate this choice with @webmozart now : )
Théo FIDRY
@theofidry
Thanks for the recap @tgalopin :)
Théo FIDRY
@theofidry
@tgalopin I could try the composer plugin for alice yesterday, works really great
Titouan Galopin
@tgalopin
that's great
would you like to start working on the plugin then? you have more experience than I do on this
(i know you have a busy agenda, no problem if you can't : ) )
Théo FIDRY
@theofidry
I won't be able to work on anything before next week, too busy with alice beta release. That said it has been extremely simple, I think you can check https://github.com/nelmio/alice as a base especially the travis.yml, and of course if you have any question or want to do a call I'll be free (not this weekend though)
Bernhard Schussek
@webmozart
Hi guys :) what do you mean by"creating a Composer plugin for Puli"? There is one already?
Théo FIDRY
@theofidry
Titouan Galopin
@tgalopin
@webmozart we meant to use the composer plugin to install puli as a binary
Titouan Galopin
@tgalopin
instead of developing a real generic installer
Tobias Nyholm
@Nyholm
Just a reminder about the hangout today at 16.00 CEST. Read more at https://github.com/puli/issues#join-the-discussion
Bernhard Schussek
@webmozart
I won't make it today, I'm hiking in Croatia. See you soon! :)
Tobias Nyholm
@Nyholm
Okey, that sounds great! See you next week
Tobias Nyholm
@Nyholm
I’ve joined the hangout now
Théo FIDRY
@theofidry
I'm there as well
Tobias Nyholm
@Nyholm
Did you follow the link from the site? https://github.com/puli/issues#join-the-discussion
Théo FIDRY
@theofidry
ah soz I went for the calendar link
I'm on it*
Tobias Nyholm
@Nyholm
Let’s meetup here so people without the calendar invite could join
Théo FIDRY
@theofidry
@tgalopin?
Titouan Galopin
@tgalopin
sorry, not available
Théo FIDRY
@theofidry
nw
Tobias Nyholm
@Nyholm

Thèo and I discussed the composer plugin, monolith repo strategy and that puli/issues#198 should be worked on this week.

We have to be aware of potential package conflicts when using a Phar and composer plugin. Théo may want to fill in with some details.

Théo FIDRY
@theofidry

Yep, so basically when you bundle a PHAR, your dependencies are not isolated. So for example PHPUnit is using symfony/yaml. So it PHPunit is using symfony/yaml 3.1 and your library is using symfony/yaml 2.8, because it's a PHAR you won't notice any dependencies conflict, but when you'll run your test via the PHAR the symfony/yaml used will be symfony/yaml 3.1 so it can break your code, go unoticed or cause some weird bug. It's more a PHP problem than PHARs are the only way to solve this issue would be to rename namespaces, which can break some code. Say for example if you do:

$class = $dummy->getFooClass();
$x = new $class();

This would break. So that's why dependencies in PHARs are not completely isolated. So whenever you want to use a tool (even if it's a dedicated application), as soon as it executes your code, it should be a dev dependency and not a PHAR or a dependency installed via another package.json like it would happen with https://github.com/bamarni/composer-bin-plugin.

Titouan Galopin
@tgalopin
wouldn't this be solved by using a composer.json in a "bin" directory as we proposed ?
as the dependencies would be different than the project's
Théo FIDRY
@theofidry

We also discussed a bit on monolith repo management. As always there is pros and cons everywhere.

For non-monolithic repositories, i.e. everything is splitted in dedicated repositories:

  • pros
    • each repo can have its own setup without any risk of affecting the step of another part. For example if you require a weird dependency, you are sure it will only affect this repo and not another one. So you have a better isolation and easier setup regarding that point
    • it's easier to seperate things well: if you are on a monolithic repositories, it's easier to mix something that should be Symfony specific for example in something that should not
  • cons
    • slightly harder to manage as soon have you have a cross-repository change
    • harder to apprehend if you are not familiar with the code-base

For monolithic repositories, it's a bit the opposite. However I must say thanks to the composer plugin I had quite a pleasant experience when doing it for alice (https://github.com/nelmio/alice) than for https://github.com/api-platform/core and another library of mine.

The two biggest issues I've seen with monolithic repositories were:

  • it's way easier to mix things up. For ApiPlatform for example, it's hard to tell what belongs to the Symfony specific and what's not; everything is supposed to be separated by namespaces (and it is), but it's a bit harder to tell at the functionality levels
  • you easily run in dependencies conflict. For a library of mine I had a bridge for Laravel and Symfony, but I couldn't require both as a dev dependency as they would conflict.

To the first problem, my "solution" is to stick a framework bridge in a library to exposing a configuration and registering services to the DIC. Anything past that should be done in a dedicated bundle/provider/etc.

To the second the composer plugin made it extremely easy. For example for alice for the symfony bridge, thanks to the plugin I only had to do:

$ composer bin symfony require symfony/framework-bundle
$ composer bin symfony require nelmio/alice:dev-master # you have to include the library itself still if you want to test it against your library

And then for testing the Symfony bridge of alice, I just have to use the vendor-bin/symfony/vendor/autoload.php instead of the default vendor/autoload.php one and play with PHPUnit groups to test only what I want. So it allows me to easily achieve a certain level of isolation without requiring to make the bridges in dedicated repositories.

@tgalopin nope, it's exactly the same problem :/ The only fix that could work would be to achieve perfect isolation by renaming the namespaces which as I mentionned is very tricky
Titouan Galopin
@tgalopin
I won't be able to come this afternoon
this time is not available for me anymore (school) so if it's possible to set it at 2pm or even 1:30pm that would be awesome :)
Tobias Nyholm
@Nyholm
I'll try to come. But I've got not computer. Mine is on service since last week :(
Romain Gautier
@romqin
This message was deleted
This message was deleted
Bernhard Schussek
@webmozart
Hi all! Back from vacation and looking forward to our next meeting :) Unfortunately I can't make it today
Théo FIDRY
@theofidry
oh :(
@Nyholm @tgalopin you can make it today?
@webmozart Beau Simensen looked really interested in Puli at the Symfony Live in London, you should invite him at the next Puli Hangout ;)
Tobias Nyholm
@Nyholm
I think so, I have a phone meeting now, Not sure if it is over in 15 minutes or 45