These are chat archives for composer/composer

8th
Nov 2016
Muhammad Taqi Hassan
@muhammadtaqi
Nov 08 2016 06:19
Should we commit the composer.lock file or not?
Rob
@alcohol
Nov 08 2016 07:21
it depends
for project roots, generally yes. for libraries, not really.
binarious
@binarious
Nov 08 2016 13:29
My php -n -dextension=/usr/local/opt/php70-intl/intl.so -d memory_limit=-1 /Users/MYUSER/projects/composer.phar update command hangs on Resolving dependencies through SAT. Waited now for 1h. Any ideas how to debug this? (Composer v1.2.2)
Rob
@alcohol
Nov 08 2016 13:29
other than using strace?
no, not really
did you try adding the --no-plugins flag?
(assuming you have plugins, otherwise ignore)
binarious
@binarious
Nov 08 2016 13:30
I don't have composer plugins. Already using php -n to disable php plugins (like xdebug).
Rob
@alcohol
Nov 08 2016 13:30
i meant composer plugins
binarious
@binarious
Nov 08 2016 13:32
Don't have them either.
binarious
@binarious
Nov 08 2016 13:43
@alcohol how is strace helpful here? The osx equivalent dtruss just gives me this output at the 'end':
open("/Users/MYUSER/projects/composer.phar\0", 0x0, 0x1B6)       = 8 0
fstat64(0x8, 0x10688DE38, 0x1B6)         = 0 0
lseek(0x8, 0x0, 0x1)         = 0 0
lseek(0x8, 0x49DAE, 0x0)         = 302510 0
read(0x400000008, "<?php\n\n\n\n\n\n\n\n\n\n\n\nnamespace Composer\\DependencyResolver;\n\n\n\n\n\n\nclass Problem\n{\n\n\n\n\nprotected $reasonSeen;\n\n\n\n\n\nprotected $reasons = array();\n\nprotected $section = 0;\n\nprotected $pool;\n\npublic function __construct(Pool $pool)\n{\n$this->pool = $pool;\n}\n\n\n\n\n\n\np", 0x2000)        = 8192 0
lseek(0x8, 0x4B447, 0x0)         = 308295 0
lseek(0x8, 0x4B447, 0x0)         = 308295 0
close(0x8)       = 0 0
Rob
@alcohol
Nov 08 2016 13:43
define "end" ?
binarious
@binarious
Nov 08 2016 13:44
when nothing happens. Shortly after "Resolving dependencies through SAT".
Rob
@alcohol
Nov 08 2016 13:44
did you specify -vvv ?
binarious
@binarious
Nov 08 2016 13:44
yes I did
Last output there is [1062.3MB/13.29s] Resolving dependencies through SAT
Rob
@alcohol
Nov 08 2016 13:45
1gb of ram already? holy cow
binarious
@binarious
Nov 08 2016 13:46
yeah, sometimes grows up to 3gb - that's no edge case for me.
But nothing more happens after this close(0x8) line, but the php process still runs at 99% cpu.
Rob
@alcohol
Nov 08 2016 13:47
well
strace only sees system calls
not low level stuff
binarious
@binarious
Nov 08 2016 13:49
and that read line with class Problem isn't a actually a problem?
Rob
@alcohol
Nov 08 2016 13:49
no
you can try running composer with xdebug profiling and a debugger like phpstorm
to see what it is actually doing
but with a dependency graph that generates nearly 3gb worth of rules
well
its no small wonder shit hits the fan
you probably should work on improving your constraints
binarious
@binarious
Nov 08 2016 13:53
hmm too bad. I defined about 25 stable dependencies (not that much imo).
Rob
@alcohol
Nov 08 2016 13:53
25 is pretty insane
and it really depends on your constraints
the broader they are, the worse it gets
binarious
@binarious
Nov 08 2016 13:54
How is that insane? 12 of them are corporate bundles alone.
So you mean fixing version numbers?
I'm also using a satis repository. Maybe that could be a problem.
Rob
@alcohol
Nov 08 2016 13:55
i mean better constraints, not sure what "fixing version numbers" means
i'm not a fan of "bundles"
so cant comment on that
pastebin your composer.json
binarious
@binarious
Nov 08 2016 13:57
Well extracting printing, payment, validation, style, etc. functionality from a project to use it different project makes sense for me. This has grown to 12 "bundles". What do you mean by constraints then?
Sure, just a sec :).
Rob
@alcohol
Nov 08 2016 13:58
if you actually frequently re-use them, then yes, it makes sense. i rarely see that being the case though.
binarious
@binarious
Nov 08 2016 13:59
yes, we re-use them a lot. Almost in every project. At least most of the bundles.
https://gist.github.com/binarious/523aa8d0fd91f3681607c782f2e8b50d
Rob
@alcohol
Nov 08 2016 14:00
regarding your duplicate scripts section, you might want to read https://getcomposer.org/doc/articles/scripts.md#referencing-scripts
you have a lot of constraints that allow patch upgrades only. that is probably best in a large dependency graph.
binarious
@binarious
Nov 08 2016 14:01
ah thanks
Rob
@alcohol
Nov 08 2016 14:01
the ones that are set to ~x.y or x.* should probably be replaced with x.y.* variants
oh god damnit markdown
binarious
@binarious
Nov 08 2016 14:02
nvm, got it anyways. will try that
Rob
@alcohol
Nov 08 2016 14:02
and then use the outdated command to see if you are running significantly behind on minor updates
and occasionally try to update those manually
binarious
@binarious
Nov 08 2016 14:04
didn't know that either. will also try that.
binarious
@binarious
Nov 08 2016 14:14
Already running for ~10 minutes now.
Rob
@alcohol
Nov 08 2016 14:22
meh
how much ram do you have?
binarious
@binarious
Nov 08 2016 14:22
16 gb
Rob
@alcohol
Nov 08 2016 14:23
since you have private packages, i cant even try to reproduce this
i really recommend you run it with xdebug profiling
see if it gets stuck in some weird loop somewhere
binarious
@binarious
Nov 08 2016 14:24
I tried removing some packages and it seems to be payum/payum-bundle which is making problems.
Do you see any problems with this package? https://packagist.org/packages/payum/payum-bundle
Rob
@alcohol
Nov 08 2016 14:25
hard to determine that
since you allow a range of versions
also i am confused
i dont see that bundle in your composer.json pastebin
binarious
@binarious
Nov 08 2016 14:26
It's inside myvendor/payment-bundle.
Rob
@alcohol
Nov 08 2016 14:26
?
binarious
@binarious
Nov 08 2016 14:26
This bundle also has dependencies.
Rob
@alcohol
Nov 08 2016 14:27
ugh
binarious
@binarious
Nov 08 2016 14:27
But removing payum/payum-bundle from it resolves the problem.
Would it be useful to add payum-bundle's requirements to my composer.json?
Rob
@alcohol
Nov 08 2016 14:30
not if the dependency is explicitly required by your payment-bundle
moving it would not make a difference (or should not, at least)
binarious
@binarious
Nov 08 2016 14:39
Ok, thanks for your time. I think I've messed up different symfony versions - will debug it.
Rob
@alcohol
Nov 08 2016 14:39
?
binarious
@binarious
Nov 08 2016 14:40
payum-bundle requires Symfony 2.8, but my packages require Symfony 2.7. That error occurs when I remove some packages, but takes a while to be found.
Rob
@alcohol
Nov 08 2016 15:04
welp
it should bail on that pretty fast imho
if it does not, that is weird
binarious
@binarious
Nov 08 2016 15:05
[991.0MB/45.06s] Dependency resolution completed in 30.395 seconds
[991.0MB/45.06s] Your requirements could not be resolved to an installable set of packages.
[991.0MB/45.06s]
  Problem 1
    - Conclusion: don't install symfony/symfony v2.8.13
30 secs it pretty long, right? Usually this fails right away after 2 seconds.
Rob
@alcohol
Nov 08 2016 15:06
45 seconds is still long, but at least not as bad as running for over 10 minutes with no feedback
binarious
@binarious
Nov 08 2016 15:09
Got it. It's downloading dependencies now :). The problem was conflicting symfony versions. That does seem to take a lot of time when you have strange setups like me.
Rob
@alcohol
Nov 08 2016 15:09
yea