Dependency errors when installed with prefer-lowest about compiler HOT 12 OPEN

Hello :-),

Hoa uses a rolling-release approach, and thus, does not recommend to use the --prefer-lowest option when installing its dependencies.

from compiler.

@Hywan I'm not sure to follow, why using a rolling release approach shouldn't be used with --prefer-lowest? --prefer-lowest is kinda mandatory for any lib wishing to ensure its minimal constraints are working fine

from compiler.

@Hywan Thanks for reply.
That is quite unfortunate. It's an abuse of versioning and causes real-world problems.
Last time I had to put Composer conflicts in place to make it work: https://github.com/schmittjoh/serializer/pull/900/files#diff-b5d0ee8c97c7abd7e3fa29b9a27d1780R46 - that is only a work around that should not exist, library should not depend on incompatible versions.
This is going to be (actually already is) a serious problem for your consumers. :(

from compiler.

We are having an internal discussion about whether we should drop Rush in favor of strict semver, or add constraints everywhere. What I can ensure you is that your problem will be fixed :-).

from compiler.

The discussion turns to be: We will finish the rewrite of Hoa for PHP 7.1-2, and then we will drop the rolling release approach to go to a strict semver. Will it work for you?

from compiler.

Few things here indeed:

• the release model is indeed problematic, and we can't use any Hoa component as a dependency in a library because of that, because the rolling release implication cascade to end consumers even if intermediate libraries are SemVer based
• --prefer-lowest is an absolute must for testing libraries and dependencies, and becomes more and more important as the number of consumer grows. This is also a good indicator of when bumping the minimum dependency version is needed.

@Majkl578 until this issue is solved (or at least re-opened) we really can't add a dependency here: the implications are massive.

EDIT: clarifying further on this bit:

we can't use any Hoa component as a dependency in a library because of that

Hoa can safely be used in applications, where dependencies are locked, but a rolling release library absolutely cannot be used as a dependency of a library (any library).

I know this is absolutely breaking the eggs in your basket, but we'll need some sort of very clear agreement on how to constrain dependencies before moving forward (should work with the ^ caret operator of composer).

from compiler.

Let me rephrase a little bit :-).

Hoa adopts rolling-release, but uses a semver-compliant versionning number to be compatible with the rest of the world. So that's why you can safely require ~3.0 for instance. This is what we call Rush Release, https://hoa-project.net/En/Source.html#Rush_Release, for Rolling Und ScHeduled Release.

I'm not very familiar with --prefer-lowest. I can work to make it work because it seems to be important. What does it do exactly?

from compiler.

One solution on your side seems to write:

"hoa/compiler": "~3.18, >= 3.18.05.15"

but it's annoying for you.

Or, we can switch the whole Hoa ecosystem to semver strictly. We are in a middle of huge refactoring for PHP 7.1, so… we can tag all new libraries as semver only and drop rush versionning, it does not sound like a big deal in our context. cc @vonglasow

from compiler.

I'm not very familiar with --prefer-lowest. I can work to make it work because it seems to be important. What does it do exactly?

Using composer install/require with --prefer-lowest instructs composer to install lowest possible versions (according to their constraints) of your dependencies and also all their dependencies.
See the difference below - first one will install the latest (default behavior), second one will install the lowest.

$ composer require hoa/compiler:^3.17
Package operations: 13 installs, 0 updates, 0 removals
  - Installing hoa/exception (1.17.01.16): Loading from cache
  - Installing hoa/event (1.17.01.13): Loading from cache
  - Installing hoa/consistency (1.17.05.02): Loading from cache
  - Installing hoa/visitor (2.17.01.16): Loading from cache
  - Installing hoa/ustring (4.17.01.16): Loading from cache
  - Installing hoa/protocol (1.17.01.14): Loading from cache
  - Installing hoa/zformat (1.17.01.10): Loading from cache
  - Installing hoa/iterator (2.17.01.10): Loading from cache
  - Installing hoa/compiler (3.17.08.08): Loading from cache
  - Installing hoa/regex (1.17.01.13): Loading from cache
  - Installing hoa/math (1.17.05.16): Loading from cache
  - Installing hoa/stream (1.17.02.21): Loading from cache
  - Installing hoa/file (1.17.07.11): Loading from cache

$ composer require hoa/compiler:^3.17 --prefer-lowest
  - Installing hoa/exception (1.16.01.11): Loading from cache
  - Installing hoa/consistency (1.16.01.11): Loading from cache
  - Installing hoa/event (1.16.01.11): Loading from cache
  - Installing hoa/visitor (2.16.01.11): Loading from cache
  - Installing hoa/ustring (4.16.01.11): Loading from cache
  - Installing hoa/protocol (1.16.01.11): Loading from cache
  - Installing hoa/zformat (1.16.01.14): Loading from cache
  - Installing hoa/iterator (2.16.01.11): Loading from cache
  - Installing hoa/compiler (3.17.01.10): Loading from cache
  - Installing hoa/math (1.16.01.15): Loading from cache
  - Installing hoa/regex (1.16.01.15): Loading from cache
  - Installing hoa/core (1.14.09.16): Loading from cache
  - Installing hoa/stream (0.14.09.16): Loading from cache
  - Installing hoa/file (1.16.01.14): Loading from cache
Package hoa/core is abandoned, you should avoid using it. Use hoa/consistency instead.

Thus, using "hoa/compiler": "~3.18, >= 3.18.05.15" solves nothing when it comes to indirect dependencies.

Also note that using tilde is not ideal (since it has confusing behavior), caret is preferred: https://getcomposer.org/doc/articles/versions.md#tilde-version-range-

We are having an internal discussion about whether we should drop Rush in favor of strict semver, or add constraints everywhere.

Imho in the end, this will be a huge win for you too, since your consumers will be familiar with it and confident when using Hoa, unlike current versioning, which is confusing to some people. 👍

We will finish the rewrite of Hoa for PHP 7.1-2, and then we will drop the rolling release approach to go to a strict semver. Will it work for you?

Sounds good to me, do you have any timeline?
Could we possibly help somewhere? I am actively working on Hoa\Compiler integration in PHP 7.2 code bases currently (Doctrine, also JMS linked above) so 5.x interfaces are a bit limiting. :)

from compiler.

We will finish the rewrite of Hoa for PHP 7.1-2, and then we will drop the rolling release approach to go to a strict semver.

If you do, that will be damn ace! Thanks!

from compiler.

I'm glad you are happy with our decisions :-). Indeed, the Rush Release format is not compatible with --prefer-lowest.

Sounds good to me, do you have any timeline?

I've been very absent these past months for personal reasons. I consider I'm back on tracks now. We are planning a Hoa Virtual Meeting (http://discourse.hoa-project.net/t/hoa-virtual-meeting/22/33) to elaborate a plan and a timeline to finish this PHP 7.1-2 rewrite. Note that all timelines are not written in stone, this is more a less a goal we try to reach.

Could we possibly help somewhere? I am actively working on Hoa\Compiler integration in PHP 7.2 code bases currently (Doctrine, also JMS linked above) so 5.x interfaces are a bit limiting. :)

Thanks for the proposal! So far, I've mainly been the only one working on the PHP 7.1-2 rewrite. I think we will come with a plan or a guide describing steps to follow to update the code. So since then, everything you can do is to subscribe to hoaproject/Central#75 I guess.

Many thanks for your feedbacks and the trust you put in Hoa :-).

from compiler.

Update for the people not reading the other thread. Refactoring to make hoa php 7 is on going.

My personal target is mid-February, but let's keep March the official deadline. (2019)

from compiler.