-
-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Symfony.lock changes during composer install #379
Comments
I noticed the same problem. This is normal? |
Issue source is line endings in different OS, so run |
Im sure this is a proper workaround. |
|
Thank you for your feedback, @fabpot. |
Nice Flex 1.2 update, @fabpot! |
Would you mind having a look? The code is also yours to debug ;) |
Sure. Line 288 in 7f04fb5
On Line 315 in 7f04fb5
(Otherwise the Lockfile will be written, too. But that should never be the case on composer install .)
So the question is why is it needed to run Flex on |
This PR was merged into the 1.2-dev branch. Discussion ---------- only write lock when its content has changed Fixed #379 by only writing the Lockfile when something has changed (which is not the case on `composer install`). This seems to me the best solution for the linked issue: * no change in the Flex behaviour on `composer install` needed (still doing the same like on `composer update`) * only update the Lockfile when needed (even the modification timestamp will stay the same) * working for all composer actions (because of auto detection) Thank you for your feedback. Commits ------- ffe345f only write lock when its content has changed
This PR was squashed before being merged into the 1.5-dev branch. Discussion ---------- compare data before marking lock as changed In #479 I tried to fix the issue #379 by introducing a _changed_ flag to the Lock. This patch worked for a few months. However, introducing #576 broke the patch by [always calling](https://github.com/symfony/flex/pull/576/files#diff-46b78198ae7ea525f04268205dd782c3R273) `set` ending in the same situation as before. Blame on me for not checking if anything differs before setting the _changed_ flag. This PR tries to do better. Commits ------- bc400be compare data before marking lock as changed
How is this closed? It seems that composer install should not be attempting to update symfony.lock at all, but the solution is only to not update it unless recipes have changed? How is this acceptable? It shouldn't be updated even if recipes change. My expectation is that if it is not going to be able to install and use only what is in symfony.lock it should fail. |
With a bit of luck this is finally fixed by #794 |
I discovered a strange behaviour when deploying Symfony Flex applications on Windows using Git and Composer. Somehow the line endings in
symfony.lock
are changing duringcomposer install
. Maybe someone can give me a hint what I'm doing wrong or what I can do better.The Environment:
core.autocrlf=true
on both machinesSteps to reproduce:
Create a new project on dev
composer create-project symfony/skeleton demo
symfony.lock
is created usingLF
charater as line endings ✔️Add everything to Git
cd demo
git init
git add -A
A warning is displayed but
symfony.lock
still hasLF
line endings in working copy ✔️Commit & Push
git commit -m "init"
git remote add origin https://...
git push -u origin master
Clone project on prod machine
git clone https://... demo
symfony.lock
now hasCRLF
line endings (because ofcore.autocrlf=true
) ✔️Check status
cd demo
git status
Install project
composer install
symfony.lock
now hasLF
line endings ❓check status again
git status
So my question is why is
symfony.lock
updated duringcomposer install
? Is that an expected behaviour? I thougth it should be read-only during install just likecomposer.lock
?Everytime I update my project on production I will have to revert the changes to
symfony.lock
before I can do agit pull
. Thats not very intuitive.The text was updated successfully, but these errors were encountered: