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

g089h515r806 created an issue. See original summary.

g089h515r806’s picture

Title: composer is useless for chinese users » Composer is useless for chinese users
g089h515r806’s picture

Issue summary: View changes

Sometimes it is blocked, Sometimes it works after you wait a lot of time.

jian he’s picture

Some 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.

heddn’s picture

Can we explain why Chinese is special? Is it because internet is slow or because of the great firewall of china?

catch’s picture

Is 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.

mglaman’s picture

I'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.

g089h515r806’s picture

Yes, 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.

cilefen’s picture

Does composer --prefer-dist help?

mglaman’s picture

The issue might also be the Packagist CDN, too. So --prefer-dist won't do much, correct?

Mixologic’s picture

Somebody 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.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

g-brodiei’s picture

Looks 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.

Mixologic’s picture

There'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.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Category: Bug report » Feature request
Issue summary: View changes
Status: Active » Closed (works as designed)
Issue tags: +Bug Smash Initiative

Triaging 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!