opened
ThomasLandauer
username_0
I'm suggesting the exact opposite of https://github.com/phar-io/phive/issues/223#issue-551360394 :-)

Reason: When I use a tool, I always want the **latest version.** Since there are no dependencies, constraining them to some version doesn't make sense to me. So installing everything with `*` as version, would save people from having to run `phive outdated` and then upgrade manually.

However, I also see the point of @username_1 in the above comment. Compromise? Maybe a switch during phive installation to enable such an "eager" upgrade feature. Intended side effect: This would Inform people that phive does have an update feature at all ;-)
Install tools with `*` as version by default
issue
created
Aerendir
username_1
My issue wasn't to use a fixed version by default.

Anyway, given your issue, maybe a behavior like the default one of Composer could be better.

So, if you specify a version when installing a dependency, Phive will use it.

If you don't specify a version, then Phive will use the last one available.

But using the * is the worst practice possible, whichever is the package or it's purpose in the project: it is not predictable and not reliable.

It's almost a "worst practice".

It also forces you to solve issues immediately, breaking your workflow...

Are you sure you are right with this approach?
comment
created
ThomasLandauer
username_0
I don't run any of the phive tools automatically. I start them manually, whenever I feel like it. And frankly I don't care if tools like phploc or composer-unused don't work exactly as last time ;-)

So what you're saying about `*` being a worst practice is certainly true for *packages*. But as far as I understand, the idea of  phive is to manage *tools* - which means they are just *not* essential for the project. I guess that some people do include them in their CI (which is certainly a legitimate use case). But other people don't ;-)
comment
created
Aerendir
username_1
Yes, you are right: it is a tool to manage tools... Think at Rector, or PHP CS Fixer: having a fixed version is essential...

I'm glad we agree on the conclusions :)
comment
created
theseer
username_2
This is a won't fix.

Using `*` as version constraint when none is given *will* break things. Even if it's "just" a tool, that tool might be essential for ones workflow and having to upgrade configuration files or tests just *now* just because the tool got upgraded is utterly useless.

Phive already supports specifying a version constraint at installation time and, as @username_1 wrote, will use what is seen as the latest version when none is specified. That's exactly how I'd expect a tool like `phive` to work.
comment
closed
theseer
username_2
issue
created
ThomasLandauer
username_0
@username_2 Well, OK, so what's your recommended way to get `*`?
comment
created
theseer
username_2
Admittingly, there is no way as of right now.

I for some time have the idea to add an `upgrade` command which will basically ignore any existing version constraint and just installs the latest version. Like `install` would do, when no constraint is given.

But this so far only exist as a PoC in local branch ;)
comment
created
ThomasLandauer
username_0
@username_2 Well, sounds good too :-)

However, I can't see why my suggestion would break anything. For any existing user, their `phars.xml` wouldn't be changed anyway. And new users don't have anything yet, so there's nothing to break ;-)

The real issue is:
* Some users want auto-upgrade
* Some users want fixed versions

So there should be two "modes", and it comes down to the question *when and where* you want to separate those modes and inform users about it:
* Upon installation. That's what I suggested above. If you don't like the idea that `phive install foo` leads to `*`, this could be changed so that `phive install foo *` leads to `*` (and `phive install foo` stays as it is)
* Upon upgrade. That what you're suggesting with a special `upgrade` command.

So which is easier to implement and which is easier to explain?
comment
created
theseer
username_2
I honestly fail to see your use case.

With a pre-existing `phars.xml` / `phive.xml` file, any call to `phive install` will try to recreated the exact version that used to be installed. Overwriting this to `*` would be just plain wrong and broken beyond any repair. (You can of course explicitly specify a different version of something to be installed, ignoring the previously installed version.)

So that leaves `phive update`:

Why anyone would want to uncontrollably get a breaking new major version of anything installed is beyond me. Semver exists for a reason and major version changes mean BC breaks. There is literally no sane use case for this behavior as you describe it, imho.

If you really insist on having `*` for updates, feel free to edit the `phars.xml` / `phive.xml` file and change the version constraint to become `*`. But again, in my opinion that's just insane to do.


I don't know what you mean by "fixed version" btw.: Phive is perfectly capable to handle version constraints like `^1.x.y`, getting you everything as long as the major version is `1`. That's not a fixed version. You can, of course, also pin phive to install an exact version, but I'm also not sure that would be useful, but the version constraint syntax supports that.

I thus recommend using the `upgrade` command - once it's implemented - to get a controlled update path.
comment
created
ThomasLandauer
username_0
I'm using it to manage some (frankly) rather unimportant tools like phploc. I run them *manually* once in a while. So in fact, they just cannot "break" for me: phploc will always produce *some* output, even after 5 major version bumps...
So having some sort of "auto update" feature would just be nice, and save me from having to manually check for new (major) versions, (almost) every time I use those tools.
comment
created
theseer
username_2
Again, feel free to change the `.phive/phars.xml` / `phive.xml` file manually if you know what you're doing.
comment
created
ThomasLandauer
username_0
No, sorry, the only thing that can "break" are my eyes when I look at the results ;-) If I get some errors, and I have time, I will take care of them and do what needs to be done. If I don't have time, I'll just ignore it, and *will not know how many lines of code I have* - who cares? ;-)

All you're saying is true for *mission-critical* tools. What I'm trying to convince you is that there are use cases beyond this. Let's call 'em "just-for-fun" tools...
And I think that ultimately it should be the users' choice which upgrade behavior they prefer for their tools.
comment
created
theseer
username_2
This discussion is leading nowhere.
comment
created
Aerendir
username_1
@username_0 , I now understand your point, also if I don't chare it at all.

Anyway, considering your usecase, maybe you can giva a try to https://github.com/bamarni/composer-bin-plugin

But I continue to think that Phive should not implement what you are asking for. Sorry.
comment