Doesn't install when using doctrine-module 3

[mesl1012]

I am trying to install this with my laminas project using doctrine but it seems to have some conflicts with installing..

    - Conclusion: remove laminas/laminas-mvc 3.1.1
    - Conclusion: don't install laminas/laminas-mvc 3.1.1
    - doctrine/doctrine-module 1.1.0 requires zendframework/zend-mvc ^2.5.2 -> satisfiable by zendframework/zend-mvc[2.7.11, 2.7.12, 2.7.13, 2.7.14, 2.7.15, 2.5.2, 2.5.3, 2.6.0, 2.6.1, 2.6.2, 2.6.3, 2.7.0, 2.7.1, 2.7.10, 2.7.2, 2.7.3, 2.7.4, 2.7.5, 2.7.6, 2.7.7, 2.7.8, 2.7.9].
.....
....
- Conclusion: don't install doctrine/doctrine-module 4.0.1|install doctrine/doctrine-module 1.0.0|install doctrine/doctrine-module 1.0.1|install doctrine/doctrine-module 1.1.0
    - Conclusion: remove doctrine/doctrine-module 4.0.1|install doctrine/doctrine-module 1.0.0|install doctrine/doctrine-module 1.0.1|install doctrine/doctrine-module 1.1.0
    - laminas-api-tools/api-tools-doctrine 2.3.0 requires phpro/zf-doctrine-hydration-module ^2.0.1 || ^3.0 || ^4.1 -> satisfiable by phpro/zf-doctrine-hydration-module[v2.0.1, v3.0.0, v4.1.0].
    - phpro/zf-doctrine-hydration-module v3.0.0 requires doctrine/doctrine-module ^1.2 -> satisfiable by doctrine/doctrine-module[1.2.0].
    - phpro/zf-doctrine-hydration-module v4.1.0 requires doctrine/doctrine-module ^1.2 || ^2.1.7 -> satisfiable by doctrine/doctrine-module[1.2.0, 2.1.10, 2.1.7, 2.1.8, 2.1.9].
    - phpro/zf-doctrine-hydration-module v2.0.1 requires doctrine/doctrine-module ~1.0 -> satisfiable by doctrine/doctrine-module[1.0.0, 1.0.1, 1.1.0, 1.2.0].
    - Can only install one of: doctrine/doctrine-module[1.2.0,
4.0.1].
    - Can only install one of: doctrine/doctrine-module[2.1.10, 4.0.1].
    - Can only install one of: doctrine/doctrine-module[2.1.7,
4.0.1].
    - Can only install one of: doctrine/doctrine-module[2.1.8,
4.0.1].
    - Can only install one of: doctrine/doctrine-module[2.1.9,
4.0.1].
    - Installation request for doctrine/doctrine-module (locked at 4.0.1) -> satisfiable by doctrine/doctrine-module[4.0.1].

[TomHAnderson]

Post your composer.json

[mesl1012]

"php": "^7.1",
"laminas/laminas-component-installer": "^1.0 || ^2.1",
"laminas/laminas-mvc": "^3.1.1",
"laminas/laminas-cache": "^2.9.0",
"laminas/laminas-db": "^2.10.0",
"laminas/laminas-mvc-form": "^1.0",
"laminas/laminas-json": "^3.1.2",
"laminas/laminas-log": "^2.11",
"laminas/laminas-mvc-console": "^1.2.0",
"laminas/laminas-mvc-i18n": "^1.1.1",
"laminas/laminas-mvc-plugins": "^1.0.1",
"laminas/laminas-psr7bridge": "^1.2.0",
"laminas/laminas-session": "^2.9.1",
"laminas/laminas-di": "^3.1.1",
"doctrine/doctrine-orm-module": "^3.0",
"laminas/laminas-crypt": "^3.3",
"laminas/laminas-authentication": "^2.7",
"slm/locale": "^0.4.1",
"laminas/laminas-permissions-rbac": "^3.0",
"laminas/laminas-serializer": "^2.9",
"gedmo/doctrine-extensions": "^2.4",
"doctrine/data-fixtures": "^1.4",
"laminas/laminas-test": "^3.4",
"doctrine/doctrine-laminas-hydrator": "^2.0",
"laminas/laminas-captcha": "^2.9",
"laminas-api-tools/api-tools": "~1.0",

[TomHAnderson]

I can give suggestions but the luck is up to you.

doctrine/doctrine-module 1.1.0 (from your first post) - hard code this to ^4.0
When installing use composer update not composer install
I think your problem lies with phpro/zf-doctrine-hydration-module - hard code this to ^4.1

From my perspective not much work has happened in Apigilityland since the namespace change to Laminas. This apigility-doctrine project was mine. I actively build with it but I have not tried to move to Laminas so what you're doing may be pioneering.

I'm on the Doctrine Project now and I released doctrine-module and doctrine-orm-module for Laminas. I'm about to release doctrine-mongodb-odm-module and I've submitted some PRs to the api-tools but haven't seen any movement on those PRs.

[mesl1012]

that is actually what i did on our previous project but i was actually hoping that we can finally use the newer versions of the doctrine-module package. what do you think if i just make another project just for the API and another project for the laminas project itself.. so that i wouldn't have this kind of problem with packages.. what do you think? Thank you for the quick reply.

[TomHAnderson]

Most of the changes in the Doctrine modules was to bring them to the standard of the Doctrine Coding Standard and composer changes to use Laminas. I did my best not to change anything except the hydrator; doctrine/doctrine-laminas-hydrator is the shiny new thing about the modules. So, if you don't have issues with the old hydrator then it is my opinion that you should stick with zfcampus until attention is turned to api-tools.

As for an API project and Laminas project I think you're doing it all wrong. The obvious shines through first like managing Doctrine metadata files between projects but that's not the problem. The problem is you're not writing a front end in Angular or a similar tool. Your whole project should be only the API. Build your microservices first, not 3 iterations through multiple re-writes as is the trend. Building a front end application in Laminas or Mezzio is the wrong way to build a front end. You can do everything in the API you could imagine doing in Laminas or Mezzio except rendering content because that is the job of Angular (or whatever else like Angular).

[mesl1012]

i actually use my API for our mobile app only so i am doing this approach. could there be a better approach? I really appreciate your insights on this. thanks!

btw, thank you for the great contribution you had made for apigility and your modules are awesome. i hope i could find a way for this to work like i intend it to do.. i will be waiting for the time we can integrate the newer versions of doctrine with the api-tool.. keep it up!

[TomHAnderson]

If you write an API: consume it! The same API call which returns a HAL-JSON response of a list of concerts to your phone is the same API which returns a list of concerts to your web site.

I wrote etreedb.org in 1999 and I've made a multi-year project of moving it to an API. That API is https://api.etreedb.org I suggest you use that documentation built with Apigility in combination with the open source front end for the project to expand your knowledge of front end capabilities today. p.s. api.etreedb.org endpoints which do not require extra perms are open such as https://api.etreedb.org/source/1

https://search.etreedb.org code is here: https://github.com/etreedb/search

[mesl1012]

right now the mobile app is the only one consuming the API.. but it would also be a waste if i wouldn't use the laminas-form and other laminas modules for the web.. that is why we built the website using laminas at the first place.. the API was just another feature to be able to create a mobile app and consume it.

But i know someday we would be doing something like you said.
Thank a lot.. i think we can close this now.