Update Folder Location / Update Package

[adamzero1]

Hi,

I'm not sure if this is the correct place to raise this as an issue, however I wanted to get the ball rolling.

Can the "/update" folder in the repo: https://github.com/magento/magento2-community-edition be moved into an external package e.g: magento2-update". This will allow people to get the updates without having to merge that repo back in to whatever they have.

If this is not the correct location to raise this issue, please can you point me in the right direction?

Many thanks
Adam

[vancoz]

Hi @adamzero1 we have published magento/updater project (current version is 10.0.0). This project preinstalled in "/update" folder because we would like to make installation easy and avoid one more step in installation process (installation of updater).

BTW, you do not need to recreate Magento project, you can just delete update folder and run "composer create-project magento/updater --repository-url=https://repo.magento.com/ update" to have new version of Updater.

Thank you.

[adamzero1]

Hi @vancoz,

Thank you for your response, I feel I may not have explained why I felt this was an issue correctly, however as the package is already available on repo.magento.com I think this will solve the issue I am having. So thank you for that, much appreciated.

I am curious as to how I can't find any documentation about this package anywhere, along with the fact that the list of packages on repo.magento.com isn't accessible, easily?
All references on http://devdocs.magento.com just send you to: https://github.com/magento/magento2-community-edition

The final snag I am now having is that
"magento/product-community-edition": "2.0.4" requires "composer/composer": "1.0.0-alpha10"
where as
"magento/updater": "10.0.0" requires "composer/composer": "1.0.0-beta1"

So I cannot require both in my project:
Your requirements could not be resolved to an installable set of packages.

Problem 1
- magento/product-community-edition 2.0.4 requires composer/composer 1.0.0-alpha10 -> satisfiable by composer/composer[1.0.0-alpha10].
- magento/product-community-edition 2.0.4 requires composer/composer 1.0.0-alpha10 -> satisfiable by composer/composer[1.0.0-alpha10].
- Can only install one of: composer/composer[1.0.0-beta1, 1.0.0-alpha10].
- Can only install one of: composer/composer[1.0.0-beta1, 1.0.0-alpha10].
- magento/updater 10.0.0 requires composer/composer 1.0.0-beta1 -> satisfiable by composer/composer[1.0.0-beta1].
- Installation request for magento/updater 10.0.0 -> satisfiable by magento/updater[10.0.0].
- Installation request for magento/product-community-edition 2.0.4 -> satisfiable by magento/product-community-edition[2.0.4].

Many thanks
Adam

[vancoz]

Hi @adamzero1, you are right updater and Magento 2.0.x requires different composer version.
But you should not require updater and/or add it to your composer.json - Updater is separate project, and to update updater you need to delete "update" folder from root directory and "create-project" using composer, please use this command (in root dir):
composer create-project magento/updater --repository-url=https://repo.magento.com/ update

We are working on docs about it.

Thank you.

[adamzero1]

Hi @vancoz,
Apologies, I must have misunderstood. I thought the goal of using composer was to allow people to better manage the version of magento they have along with any added extras such as the updater.

It seemed to make sense to me that I would be able to create a project that required a certain versions of both (along with any other packages I desire), making it easier for me to manage exactly what is in my project?
By splitting the updater out are you essentially saying that to have both magento2 and the magento2 updater I have to manage two separate projects? That just seems counter-intuitive to me. If there is a way I can assist in making the updater a require-able package just point me to the git repo as I think there would be a lot of value in being able to have project containing something like:

"require": {
"magento/product-community-edition": "2.0.4",
"magento/updater": "10.0.0",
"zero1/custom-dev": "dev-master",
"zero1/client-specific-module": "dev-master"
},

Many thanks
Adam

[vancoz]

Hi @adamzero1 thank you for your intention to help, we really proud of our community and really appreciate it. Let me explain to you background: Updater can not be Magento requirement - because this is tool which runs "composer update" to update Magento code (base package, modules etc...). So Updater it will be part of Magento requirement - during "System Upgrade" Updater will try to delete old version of itself and install new. This is not acceptable, component can not upgrade itself. Updater is kind of Magento firmware, main responsibility of Updater is manage(install/update/uninstall) Magento components.

You have background of this decision now, so fell free to offer some better solution, we will appreciate it.

Thank you.

[adamzero1]

Hi @vancoz ,
I appreciate that having a module that tries to update itself may cause issues, but your point is conflicting.
"main responsibility of Updater is manage(install/update/uninstall) Magento components"
You state that the magento/updater is not a component of magento, that it is a kind of firmware. If that was true then there would be no issue as the updater would never try to update itself by definition, as it is separate.
You suggest managing the current version one has of the magento/updater can be done by reinstalling the project, which is worse then it being a require-able package.

I do however appreciate that you are trying to create a solution that allow user to manage everything through a web GUI which can be challenging.
But if part of this GUI allows a user to update the version of the updater (which isn't a magento component) then you are forcing yourself to develop something that updates itself (which you have said you don't want).

To me I can see two desired functions:

• updating magento and its components
• updating the updater

The only way to avoid having an entity that updates itself would be to move the function of "updating the updater" out of the updater. If this was done, then there would be no reason that the updater could be a require-able package.
To install the updater in the first place a user would need to have access to their files (to either extract zip, git clone or composer install). So I can see no reason why a user couldn't be expected to extract an "updater" zip in the appropriate directory, possibly after deleting the update directory.

I know this seems tedious, but I am trying to look at this from managing multiple clients. I want to be able to provide a solution where a client can install modules themselves from magento connect (requiring the updater), but in the same breath I want all information on what packages and version a client contains in one location. I hope that makes sense?

Many thanks
Adam

[vancoz]

Hi @adamzero1 if we will have Updater as part of Magento requirements, that means that autoload files, vendor directory etc will be shared. So we would not be able to manage Magento dependencies and keep Updater safe from failure, that's why we need to keep Updater as separate project.

Regarding managing multiple instances - completely agree with you, I'm sure that we need to make easy procedure how to upgrade Updater (ideally it should be part of flow in Setup Wizard and right now we are looking for way how to implement it - for example Setup Wizard (which is part of Magento) can be responsible for it, so Updater will not try to update itself).

What about "Updater" in Marketplace (connect), I do not think that this project will be shipped as extension in connect. Currently Marketplace supports "magento-*" and "metapackage" package types, and Marketplace packages should be part of Magento (requirement) when Updater is independent tool.

Thank you.

[vancoz]

@adamzero1 do you feel that explanation is helpful and we can close the issue?

[adamzero1]

Hi @vancoz,

Apologies on the late response.
Thank you for your time on the matter, I guess I will just have to wait an see how this pans out. Especially when the marketplace is 100% up and running.

Thanks again.
Adam

[vancoz]

Hi @adamzero1, thank you. Anyway if you have more question or proposals - fell free to discuss.
Also I would recommend this place http://magento.stackexchange.com/ as platform for questions/discussions and proposals.