magento-lts

magento-lts copied to clipboard

Summary (*)

composer.lock depends on php version and we all run different setups, Does it make sense to have it in the repo?

Examples (*)

Current composer.lock seems to be for php8.0 ...

1. Create new (ddev) project with php7.x
2. run composer install
3. erros b/c locked versions do not fit

Proposed solution

Remove composer.lock

You should have separate composer json and composer lock for your projekt. This one is for openmage core only. Without it we had several situations where CI stopped working because of the upstream change in some dependency

As said ... we all have different setups, so composer install should work for all of us. The composer.lock is usefull if all run the same environment (for the same project), but not for OM itself.

Lets take the gitpod-example ... it uses php 7.3, but composer.lock is for php8.0, so composer install fails. You have to switch php-version to 7.3 and run composer update and restart gitpod.

@sreichel im ok with any approach which will give us stability on CI builds.

So what is the suggestion to get reproducible builds for gitpod? Ignoring the platform requirements might cause some compatibility issues, but at least is reproducable. Having no composer lock might cause gitpod to end up in a broken state because of a dependency which updated/changed. Enforcing more strict dependencies in composer.json would limit ALL users of OpenMage, as then they couldnt (easily) use newer versions if they need them.

If the issue is with environments where you have control and having a composer.lock at all there, you could also remove it in a separate step of your environment.

I personally make it a point to never install php and therefore composer in my dev environment and instead rely 100% on Docker.

For example for general purpose use I use this in my .bashrc:

if ! command -v composer >/dev/null; then
  alias composer='docker run --rm -it -u $(id -u):$(id -g) -e COMPOSER_IGNORE_PLATFORM_REQS=1 -v ${COMPOSER_HOME:-$HOME/.composer}:/tmp -v $(pwd):/app composer:latest --no-scripts'
fi

So perhaps we could standardize a way to run composer for OpenMage like shell/openmage.sh composer install that is a wrapper for running a docker container pegged to a specific version?

It would be recommended to users to use whatever version of PHP is used by this wrapper which is matched to the gitpod environment. If a user needed to use a different version they would delete and generate a new composer.lock in their own environment using their own tools (assuming they are managing the project as a clone).

@sreichel im ok with any approach which will give us stability on CI builds.

I really dont know, but what troubles CI not having a composer.lock?

So what is the suggestion to get reproducible builds for gitpod?

Just drop composer.lock. (gitpod = php7.3, composer.lock = php8) Without it, gitpod should work out of the box.

IMHO ... composer.lock belongs to customer projects, to ensure every developer has a env that match live system.

If i do a git clone + composer install for OM, it shoud work for every supported php version, but it does not, as long as you'r not on PHP8.

The arguments brought by @sreichel are pertinent. The current composer.lock is a file created by Composer and contains particularities that may not be found in the configuration of the system where it is located. I didn't use Composer with OpenMage, but seeing the (json + lock) files warned me in a way that there is a possibility to use Composer and that if I use it, I must have a composer.lock for the system it is running on. I think that the installation and update stage are mandatory at the beginning, so the presence of the composer.lock file in the repository should not be necessary, You could rename it composer.lock.sample if you want to keep it.

Deleting composer.lock and running composer update command has the following result:

ubuntu@ubuntu-virtual-machine:~/PhpstormProjects/magento-lts$ rm composer.lock
ubuntu@ubuntu-virtual-machine:~/PhpstormProjects/magento-lts$ composer update
you may want to add the packages.firegento.com repository to composer.
add it with: composer.phar config -g repositories.firegento composer https://packages.firegento.com
Loading composer repositories with package information
Info from https://repo.packagist.org: #StandWithUkraine
Updating dependencies
Lock file operations: 17 installs, 0 updates, 0 removals
  - Locking eloquent/enumeration (5.1.1)
  - Locking flyingmana/composer-config-reader (20.0.1)
  - Locking justinrainbow/json-schema (5.2.12)
  - Locking macopedia/phpstan-magento1 (v1.0.4)
  - Locking magento-hackathon/magento-composer-installer (4.0.2)
  - Locking phpstan/phpstan (1.8.2)
  - Locking psr/container (2.0.2)
  - Locking symfony/console (v5.4.11)
  - Locking symfony/deprecation-contracts (v3.1.1)
  - Locking symfony/polyfill-ctype (v1.26.0)
  - Locking symfony/polyfill-intl-grapheme (v1.26.0)
  - Locking symfony/polyfill-intl-normalizer (v1.26.0)
  - Locking symfony/polyfill-mbstring (v1.26.0)
  - Locking symfony/polyfill-php73 (v1.26.0)
  - Locking symfony/polyfill-php80 (v1.26.0)
  - Locking symfony/service-contracts (v3.1.1)
  - Locking symfony/string (v6.1.3)
Writing lock file
Installing dependencies from lock file (including require-dev)
Nothing to install, update or remove
7 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating autoload files
12 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
root/app/Mage.php is not a file.

@sreichel wrote:

If i do a git clone + composer install for OM, it shoud work for every supported php version, but it does not, as long as you'r not on PHP8.

I believe this is what @tmotyl was getting at, but perhaps the committed composer.lock should be considered a file for OM developers only and not for end-users? That is, the instructions for managing your project as a clone of OM repo should be to immediately delete composer.lock locally and generate it fresh in your own environment.

While merging upstream changes if the user keeps composer.lock in the repo the user would always keep the head and ignore the upstream changes to composer.lock, then manually merge changes to composer.json and run composer update again. I've managed a project with the composer.lock file in the repo and when there are lots of branches updating composer.json this is not uncommon to have to do anyway.

But on that note, I do think we will need all of our different dev/demo environments to be kept on the same PHP version which matches the one used to generate composer.lock. My proposal would be that they always use the latest supported version.

The latest version of composer.lock has already been merged yesterday into OM via PR #2378. It was generated in Ubuntu 22.04 with PHP 8.1.2 installed.

Therefore, the file will remain in the repository and there is no longer an issue of dropping it. I would suggest that we either move this post to Discussions, where it will remain for opinions or close it.

and there is no longer an issue of dropping it

Updating to latest version does not resolve my issue.

Let me think about it a few days ... :)

+1 to drop composer.lock

I moved this post to Discussions/Ideas. It can be decided at a moment of mutual agreement whether to delete this file or not.