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
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
Théo FIDRY
@theofidry
cool
Im in!
Tobias Nyholm
@Nyholm
@theofidry are you with me?
Titouan Galopin
@tgalopin
@theofidry sorry, i'm not available as i have a course (in school)
i often won't be able to come at this hour :/
Théo FIDRY
@theofidry
No worries
Tobias Nyholm
@Nyholm
Will it make a difference if we do it an hour later?
Bernhard Schussek
@webmozart
Théo FIDRY
@theofidry
Yep, perfect for PHARs but doesn't solve the issue you may have with them
Well we can discuss about that at the next hangout
Mateusz Sojda
@msojda
ping @webmozart - I’ve updated puli/manager#47 but it’s still hanging :disappointed:
Bernhard Schussek
@webmozart
thanks @msojda, I'll look at it ASAP
Mateusz Sojda
@msojda
cool, thanks :smile:
Théo FIDRY
@theofidry
@tgalopin should we change the time of the hangout for you?
Bernhard Schussek
@webmozart
It's Tuesday again! Here's the link to the Hangout: https://hangouts.google.com/hangouts/_/ynlequecnfcwzp7yatqpdh4skie
Tobias Nyholm
@Nyholm
Im going to have a look at puli/issues#198
Théo FIDRY
@theofidry
is there a Hangout today?
Tobias Nyholm
@Nyholm
Yes sir
Théo FIDRY
@theofidry
'right
Tobias Nyholm
@Nyholm
Ill be there in a minute
Théo FIDRY
@theofidry
Err sorry guys I won't be able to join this one either :/
Bernhard Schussek
@webmozart
Hi all :) anybody there today?
I made some progress last week, not entirely finished, but getting along
Stephan Wentz
@temp
@webmozart any chance to get a new puli/twig-extension release, which incorporates puli/issues#204
?
right now this forces us to use an old twig version