- Issue created by @Liam McDermott
- 🇮🇳India vishal.kadam Mumbai
There might another module which is using “ecwid” machine name.
- 🇨🇦Canada Liam McDermott
So, I'm wondering: what are the options?
If some other project already had the `ecwid` namespace, surely the site should have stopped me from registering the project? That seems like a bug.
FYI, I have registered: https://www.drupal.org/project/woolwich_ecwid → Just to get something working, but I'm still interested to know what the options are for the Ecwid namespace.
- 🇮🇹Italy apaderno Brescia, 🇮🇹
drupal/ecwid is already used from the Ecwid Ecommerce Shopping Cart → project, whose main module's machine name is ecwid.
As for fixing the difference between the module namespace and the Composer package name, you could get some information from this other issue queue. I do not know all the details to answer that part.
- 🇺🇸United States cmlara
This issue is related to the general packaging system handling of package namespaces in 🌱 Change how modules and submodule dependencies are handled to have more consistent namepsaces [DRAFT]. Active
- 🇺🇸United States drumm NY, US
This is a normal part of how packages.drupal.org handles namespaces, to prevent conflicts. In some cases, we can align the composer namespace to the project name, but these should not be expected to be the same all the time.
While this command works, it seems to cause problems with Drupal/Symfony's class autoloader. Probably because the module's code uses the namespace namespace Drupal\ecwid;, but composer puts the module code in `modules/contrib/ecwid-ecwid`.
What problems specifically? If there is something assuming project name === composer name, that bug should be tracked down.
- 🇨🇦Canada Liam McDermott
Apologies, now when I install the module, I'm not seeing any problems when the module is namespaced `ecwid` but is inside the `ecwid-ecwid` directory. Any issues I was seeing were probably caused by moving the module on my local, I was careful, but maybe there was something in config or the caches that resulted in an error being thrown.
So, the only bug (IMO) is that I was allowed to create a new module with a name that's effectively already taken, leading to a weird usability issue for anyone `composer require ecwid`-ing without carefully reading the instructions. This is an assumption, but I'm guessing most people look at the final segment of the drupal.org/project/project_name URL to get what to use in their `composer require`, and not the instructions at the bottom of the project page.
I'd prefer users not have to deal with that, so could you please delete drupal.org/project/ecwid. Then also delete drupal.org/project/woolwich_ecwid as that name kinda sucks.
If it's easier for you to rename than delete, you could rename drupal.org/project/woolwich_ecwid → ecwid_drupal (but still delete ecwid). Thank you! And sorry for being a pain.
- Status changed to Closed: works as designed
9 months ago 5:20pm 1 March 2024 - 🇺🇸United States drumm NY, US
We do not delete or rename projects, since people should be able to expect Drupal.org to host the same code at the same place indefinitely, with no possibility of a different codebase being installed.
🌱 Change how modules and submodule dependencies are handled to have more consistent namepsaces [DRAFT]. Active may change this behavior in the future.
- Status changed to Active
9 months ago 7:34pm 1 March 2024 - 🇨🇦Canada Liam McDermott
That seems a little silly, I understand why that rule exists, but no-one is using those modules yet. I only just created them!
Anyway, sorry for making a mess, I'll try to clean it up as best I can. Thanks for looking into this.
- Status changed to Closed: works as designed
9 months ago 8:46pm 1 March 2024