search

phar-io / phive

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

Design phive for teams: Add a phive.lock file #92

Closed christian-weiss closed 7 years ago

christian-weiss commented 7 years ago

To make phive a full fledged dependency manager for tool installation. You should have the developers and 'human dependency managers' in mind, when designing phive.

Splitt current phive.xml into: a) phive.lock b) phive.xml

The phive.lock is important for the developer team it describes that tools to install and what exact version to be used for each. This is a 'well tested set of tools' (tested for this team and this project).

The phive.xml is important for the 'human dependency manager' and may contain some version strings with wildcards or 'update pattern' to help the 'human dependency manger' to define a 'update strategy'. With wildcards a build server can pre-flight if new tool version are 'good enough' for this project and its result can be used by a 'human dependency manager' to decide it he wants to push a new phive.lock to the team.

phive install and phive install toolnamehere should honor the tool version, as written in the xml and lock file when installing / symlinking the tool. A 'phive install toolnamehere' should never ever update a version string in phive.lock. If the tool is not listed jet in these files 'phive install toolnamehere' should inject that tool with the most up-to-date version to this file.

Only 'phive update' and 'phive update toolnamehere' should update a tool entry in phive.lock.

Please consider to add a '--verion=versionstringhere' to 'install' and 'update' command to stop forcing humans to edit phive.xml and phive.lock.

christian-weiss commented 7 years ago

Please work on this ticket only if you reject ticket #93 (https://github.com/phar-io/phive/issues/93).

theseer commented 7 years ago

This ticket contains two unrelated issues. Let's look at both:

--version

I don't see any benefit for such a switch over simply specifying the version directly as is already supported:

phive install phpunit@5.4.*

Alternative seperators : (apt, docker) and = (yum, dnf) are also supported. (see #67)

phive.xml + phive.lock

I'm not sure I understand the use case. You can commit the phive.xml as it contains both, the version actually installed as well as the version specification given. A phive install should install exactly the versions marked as "installed". A phive update will update according to the version mask.

Why would we need to split that up into two files?

sebastianheuer commented 7 years ago

Since specifying a version (constrain) is already implemented an we do not see the need for a separate .lock file, we close this issue.