Closed (fixed)
Project:
Commerce Core
Version:
8.x-2.x-dev
Component:
Developer experience
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
24 May 2017 at 11:46 UTC
Updated:
28 Dec 2021 at 04:17 UTC
Jump to comment: Most recent
Comments
Comment #2
skyredwangAn alternative way to install would be using Docker image, please follow the instruction here: https://hub.docker.com/r/insready/drupal-commerce/
On the other hand, if you are interested in developing with Drupal Commerce, the same Docker image can help you set up everything, including Xdebug enabled as default. All you need to do is change the tag from
8.x-2.0-beta7todevIf you haven't used Docker before, you can follow this very short tutorial: https://insready.com/en/blog/testing-new-drupal-8-installation-2-docker-...
Comment #3
bojanz commentedOkay, I'm convinced. Said "NO" enough times.
We can tackle this in june post-RC1.
Comment #4
skyredwangI don't think this feature request is specific against Composer. The way mentioned in #2 also uses Composer. However, like Core, some people want a tar ball to package everything together. Maybe, this should be solved at Commerce Kickstart.
Comment #5
bojanz commentedThe general solution is to let people download each library to a non-vendor folder such as commerce/lib (either manually or using a Drush/Console command), then adding that folder to the autoloader. This however is easier said than done, the early version of composer_manager had problems hooking into the process early enough to avoid crashes (if the external code is used in an entity type loaded too early, etc). That's why we gave up on that approach and went full Composer in the first place. So, the effort will require quite a bit of experimentation with different events and ways of altering the container / class loader.
Comment #6
skyredwangNobody does this anymore, laraval or other PHP frameworks. It becomes almost impossible. Not mentioning for people just want to try out Commerce for the first time.
Think from a slightly different perspective: currently Composer plays two roles: package assembler and package distributor. This issue is about the end user having problem with the package distributor role.
Core also uses Composer, but it also provides a tar ball as an alternative distribution method. While Core is a full Drupal distribution, which makes it easier to package everything as a tar ball, Commerce is only a Drupal module, that's why I was thinking if we can follow the core and provide a tar ball of the Commerce Kickstart Distribution, then we might be just good.
On the other hand, Docker can take up the package distributor role as an alternative to Composer. It's also good fit for demoing and sandboxing Commerce for people are new.
Comment #7
drugan commentedSubscribing for the #6. There is a lot of people who does not like command line interface and does not use the applications which require it at all. Introducing a tarball drupalcommerce install method will help proliferation of the module.
More users == more testers == more robustness == more users.
Comment #8
bojanz commented@skyredwang
You don't need to tell me all this, we've been saying it for years.
In any case, we have no way to provide a functional tarball without distributing Commerce ourselves. People will need to either use Composer or download libraries manually.
Comment #10
bojanz commentedWe have just released https://www.drupal.org/project/ludwig as a way to allow this.
Tested Commerce and Address on a clean D8 install, worked fine.
Comment #12
devad commentedWe need a better title here for Ludwig integrations list:
#3174645: [LIST] Ludwig integrations in contrib modules