search

cloudinary / cloudinary_magento

Cloudinary's Magento extension. Upload product images to the cloud, manipulate them to match your graphic design and optimize images for better user experience
MIT License
16 stars 17 forks source link

Your magento subfolder setup prevents using composer for install #27

Closed ProxiBlue closed 5 years ago

ProxiBlue commented 6 years ago

Hi,

Am I missing something here? You have negated ability to use composer for install.

You have placed magento 1 and magento 2 code in subfolders in the same repo. Each has a composer.json, however composer cannot install from subfolders. (ref: https://github.com/composer/packagist/issues/472)

So basically, having done the subfolders, you have negated ability to use composer to install either package.

You should consider separate repos for magento 1 and magenrto 2 versions of the code, since, in reality they are two different platforms...

idobarnoam commented 6 years ago

Hi @ProxiBlue,

We use GH mainly to store the code. The module is intended to be installed using the Magento Marketplace.

Can you share the reason you are using the composer to install the module?

ProxiBlue commented 6 years ago

Hi,

Generally, when a FREE (or service provider module) is available via GitHub, it is usual for that version to be more up-to-date, especially due to community driven PR's and bug fixes.

By placing your code on GitHub, the community can generally help enhance, and bug fix your code, and improve the overall quality and features of the given code.

Since this is the norm, finding your code on github, it was expected to have the same outcome.

It has been normal for GitHub placed modules to be installable via composer for many years now, and it is usually also expected to be the norm.

Advantages of using composer: (just off the top of my head)

  1. usually more up-to-date code with bug fixes/features not yet pushed to MarketPlace versions of modules. More 'bleeding edge'
  2. Easy to upgrade/ update a module, by using composer, via the command line
  3. All composer based packages are not kept in the local site repo. They are external, 3rd party vendor packages, which get deployed to live environments using composer as part of the deploy process. (It is even common to deploy the magento core files as such, using composer, and not keep them in the site own repo)

Advantages of not storing vendor code (or magento core code) in site repo is prevention code edits. Many developers work on a project at the same time. It is fairly easy for one developer to accidentally make edits to a core/3rd party vendor code, and commit that into the site repo. By using composer, no vendor site code can be committed to the local repo, thus preventing such mistakes. The original vendor codee will ALWAYS be deployed via the site deploy process, which uses composer.

I hope that helps to explain. You added the composer files, so you done the effort, but then by using sub-folders, you negated that effort, which make no sense.

idobarnoam commented 6 years ago

Hi @ProxiBlue

Thanks for your patience with the reply. It took some time as I wanted to verify the information.

The original thought behind our module is that most users would install it using the Mraketplace. We are aware that this negates using the composer for install, but this is as designed.

We did take this request internally, and we would re-consider this approach and see if it should be changed.

I hope this makes sense.

CosyStudios commented 6 years ago

Also been wondering why the hell it doesnt install via composer. Turns out the core lib/CloudinaryExtension folder isnt even part of the repo so was never going to work anyway. Bit weird including the composer file, really threw me off the scent too

CosyStudios commented 6 years ago

May I +1 in favour of composer compatibility. The fact of the matter is , professional Magento sites are not built using magento marketplace. Not really even sure why the place exists, Magento should have just built a reference portal for plugins to list themselves on like drupal

idobarnoam commented 6 years ago

@CosyStudios thanks for sharing your input. We would take this into consideration.

andyt commented 5 years ago

Likewise we deploy a high-profile Magento site using docker + composer. Magento Marketplace does not feature in our deployments. I'm currently using the most recent version available on http://packages.firegento.com/.

shirlymanor commented 5 years ago

@andyt thank you for sharing. I forward it to our product team to consider adding it to our road map. we will update here with any insights.

idobarnoam commented 5 years ago

@andyt @CosyStudios the M1 and M2 repositories have been split to accommodate a composer installation for M2.
M1 does not have an official composer installation and requires manual installation. Our M1 module also supports manual installation that can be seen on the readme file in the main repository page.

We also support installation with Modman that can be used.

I hope that helps out.

ProxiBlue commented 5 years ago

@idobarnoam You can actually place a composer.json to the magento 1 module. This will still make it composer installable, and does not need to be submitted / updated to packages.firegento.com

Most deployment processes would use their own package managers, as depending on an external resource such as packages.firegento is a major point of failure. The package woudl be loaded into the custom package manager, and installed via composer, via GIT from GITHUB

However, moot point for me, as I had abandoned your module, due to lack of progress on #28 and rolled my own, more simplified version, which suits my needs.

I am closing this ticket (as original creator) as you have now split the repos, which was the premise of this ticket, and is completed.