search

phar-io / phive

The Phar Installation and Verification Environment (PHIVE)
https://phar.io
BSD 3-Clause "New" or "Revised" License
571 stars 44 forks source link

Using phive with only constraint #389

Closed dereuromark closed 1 year ago

dereuromark commented 1 year ago

We would like to use phive without having to explicitly state the exact version installed. It only creates merge conflicts across branches and (similar to lock file) is not useful for us for vendor libs to exactly track.

All we want is to commit the range (constraint), e.g. ^1.2.3 and not create further changes for it inside semver when downloading via phive install.

Right now it does however always change

<?xml version="1.0" encoding="UTF-8"?>
<phive xmlns="https://phar.io/phive">
  <phar name="phpstan" version="^1.9.12" location="./tools/phpstan" copy="false"/>
  <phar name="psalm" version="^5.6.0" location="./tools/psalm" copy="false"/>
</phive>

to

<?xml version="1.0" encoding="UTF-8"?>
<phive xmlns="https://phar.io/phive">
  <phar name="phpstan" version="^1.9.12" location="./tools/phpstan" copy="false" installed="1.9.12"/>
  <phar name="psalm" version="^5.6.0" location="./tools/psalm" copy="false" installed="5.6.0"/>
</phive>

etc

Similar to composer maybe a --no-lock option for the command?

Otherwise, the commands should also be separated into "update" pulling new versions if available and updating the lock info (in this case "installed" info) vs "install" as only installing as per setup (so "installed" info with fallback to version constraint) but not modify the lock info.

The first solutions ounds better to us. Those solutions can also be combined of course to allow more control over the file generation.

theseer commented 1 year ago

Thanks for opening an issue on this. I have to admit though, so far, I'm not understanding your use case.

Phive's phive.xml (or .phive/phars.xml) combines what composer tracks in two files (composer.json and composer.lock) into one single file. The reasoning behind that decision was (and probably still is..) that we couldn't come up with any sane use case where one would only commit either file. Indeed composer is trying very hard to make sure both files are in sync and has quite some code to verify that as well as deal with upgrading in case they diverged.

Currently, phive tries to recreate the exact set of versions as recorded when phive install without additional arguments is being used. Upgrading dependencies should be a conscious decision - in phive's case via the phive update command. Having a version constraint only will have an - depending on the constraint - arbitrary version matching that constraint installed. I cannot (yet) see any logical reason why one would want with install.

We do have an option to not record any changes (--temporary), though that so far only works in install mode. For your use case that would be required to also apply to update.

Again, I fail to see the use case.

If you want to automate upgrading tools, I'd use a CI job that simply runs the update command, then uses the tools and if everything still works, commits back the change.

This all doesn't say we cannot implement what you suggest - I just don't understand the use case ;)

dereuromark commented 1 year ago

We solved the issue for now using no semver but e.g.

  <phar name="phpstan" version="1.9.16" installed="1.9.16" location="./tools/phpstan" copy="false"/>
  <phar name="psalm" version="5.6.0" installed="5.6.0" location="./tools/psalm" copy="false"/>

This way no changes are done on the file when installing locally or on CI.