Project URI issue (Ecwid)

Created on 23 February 2024, 9 months ago
Updated 1 March 2024, 9 months ago

I registered a new project: https://www.drupal.org/project/ecwid

Which works fine, however, if you look at the composer instructions for the release I created, it says:

composer require 'drupal/ecwid-ecwid:^1.0@alpha'

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

The composer command I would expect to use:

composer require 'drupal/ecwid:^1.0@alpha'

Redirects to another project.

💬 Support request
Status

Closed: works as designed

Version

1.0

Component

Miscellaneous

Created by

🇨🇦Canada Liam McDermott

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

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

  • 🇮🇹Italy apaderno Brescia, 🇮🇹

    (I meant this other issue queue.)

  • 🇺🇸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
  • 🇺🇸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
  • 🇨🇦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
Production build 0.71.5 2024