Problem/Motivation
Composer should be optional for Drupal project and third party modules, not required. Chinese developer could not user composer directly.
Please provide another way how to install a module, instead of only provide composer way to install a third party module.
Proposed resolution
From #19, The only real option is for users within China is to set up their own proxies/mirrors for both packagist.org and, now, packages.drupal.org. See #3091061-9: Drupal-specific Full Composer Mirror
Make a proposal for an alternative method of package management can be made in the ideas queue queue.
Comments
Comment #2
g089h515r806 commentedComment #3
g089h515r806 commentedSometimes it is blocked, Sometimes it works after you wait a lot of time.
Comment #4
jian he commentedSome helper for using composer:
1. using https://install.phpcomposer.com/installer instead of https://getcomposer.org/installer
2. set COMPOSER_PROCESS_TIMEOUT to 1200
Good luck.
Comment #5
heddnCan we explain why Chinese is special? Is it because internet is slow or because of the great firewall of china?
Comment #6
catchIs this an issue with packagist.org?
Moving out of support request to bug report - while this is a third-party dependency, as we use composer more, we need to be aware of issues other than just 'using cli' that might prevent people working with it.
Comment #7
mglamanI'm pretty sure it's a firewall issue. But isn't this an issue with npm, bower, any package manager and people behind that firewall? It's related to GitHub.
Comment #8
g089h515r806 commentedYes, it is a firewall issue. Sometimes it is blocked, some time it is ok, you do not know when you are lucky.
I have experience with npm, it is ok in China.
Commerce2.x and search_api_solr only provide composer way to install them, it is very inconvenience to install them.
There will be more Drupal 8 modules provide composer way to install them, it will be better for them to provide another way without composer to install them.
Comment #9
cilefen commentedDoes
composer --prefer-disthelp?Comment #10
mglamanThe issue might also be the Packagist CDN, too. So
--prefer-distwon't do much, correct?Comment #11
MixologicSomebody just linked this in a composer issue, but since I dont speak chinese, Im not sure what it actually is.. maybe its a mirror of packagist.org?
https://pkg.phpcomposer.com
Could somebody that can speak chinese look at that and evaluate what it is that it provides?
Edit: I just noticed that this was what was suggested in #4. Note that pkg.phpcomposer.com probably does not also mirror packages.drupal.org, but hopefully the fact that we are backed by fastly will help chinese users download our data.
Comment #18
g-brodieiLooks like currently the mirror of pkg.phpcomposer.com is outdated (ref 1). Re: @mixologic, This is a China ver. mirror site for packagist.org, there are other composer mirror site within China as well.
I guess China users may try other packagist mirrors in the meantime (Dunno if that will make a difference?). What we probably need to do is update Drupal's documentation for other region users if they encounter similar issues whilst using composer.
ref 1: https://github.com/Webysther/packagist-mirror#-packagist-public-metadata...
Guess the problem/motivation comes where there isn't a mirror for packages.drupal.org. @spotzero did mention a resolution in https://www.drupal.org/project/3132609/issues/3091061#comment-13420938 to create a mirror for packages.drupal.org tho.
Comment #19
MixologicThere's not a lot we can do about the fact that composer is becoming a defacto standard for building sites. Every language has package managers, and most of those all rely on sites like github, gitlab, bitbucket, or drupal.org, all of which allow for content that the Chinese Government may find unacceptable, and may ban.
The only real option is for users within china to set up their own proxies/mirrors for both packagist.org and, now, packages.drupal.org. I outlined a plan here: https://www.drupal.org/project/3132609/issues/3091061#comment-13859663
Ultimately, there is no getting around the fact that connectivity to the rest of the development community depends upon those in control of the Great Firewall to allow it, and it has nothing to do with composer, because drupal.org has, in the past, itself been blocked.
But, Composer 2 is much faster at everything, I suggest trying to upgrade to it to see if it solves many issues you're having.
Comment #22
quietone commentedTriaging for Bug Smash.
Reading through the issue it is clear that the firewall is the component of the problem and that, of course, is not something Drupal can fix. So, not really a bug. The request here is for a new feature, some package manager that does not require composer to build Drupal sites and will not be blocked. That makes this a Feature request.
However, as pointed out in #19 composer has become the de-facto standard. There are no mentions of an alternate package manager that will not be blocked by the firewall. But then, how will we know if another package manager will be blocked or not until it actually happens?
I suggest the way forward is to open an issue in the ideas queue with a specific proposal some other tool.
Therefore, closing this as works as designed. If this is incorrect reopen the issue, by setting the status to 'Active', and add a comment explaining what still needs to be done.
Thanks!