Change or remove sub packages from drupal/operations

Facing the same issue at 🐛 Inconsistent extension module machine name (doubled for composer) Active

I've removed the submodule from the parent project, operations.

Now drupal/site points to an old version that won't be updated.

Is it even possible to switch this around?

Moving to Infrastructure queues.

Forgive me if this is not possible, I'm not sure how everything works. I don't even know if these things are editable.

Could we leave the existing Packagist releases the way they are, but change the source module for the next releases?

What would happen if we did this:

Remove drupal/site, drupal/site_manager, and drupal/operations_ui package names from https://www.drupal.org/project/operations → .
Update https://www.drupal.org/project/site → to use drupal/site.
Update https://www.drupal.org/project/site_manager → to use drupal/site_manager
https://www.drupal.org/project/operations_ui → to use drupal/operations_ui.

Then created new releases for site, site_manager and operations_ui, would those get published as the newer versions of drupal/site etc?

FYI, I have requested to change Operations to a general project. Does this affect how composer packaging works?

https://www.drupal.org/project/infrastructure/issues/3377494 →

Digging through the code, I found the place where it creates the double package name:

https://git.drupalcode.org/project/project_composer/-/blob/7.x-1.x/proje...

Looks like the only time project_composer_namespace_map gets updated or deleted, it looks for duplicates from

_project_composer_get_packagename_from_component() 

Does this mean that the only solution here is to delete rows manually from project_composer_namespace_map?

Is that possible?

I think if this was run, then I created new releases for the submodules, it would create a new mapping for those projects?

DELETE FROM {project_composer_namespace_map} WHERE project_nid = 3366014;

packages.drupal.org was the correct queue for requesting namespace switches from what is working as designed. Composer namespaces do not necessarily match project names.

🌱 Change how modules and submodule dependencies are handled to have more consistent namepsaces [DRAFT]. Active would be the general change to the current behavior.

Hashing out options...

For reference:

• Table: project_composer_namespace_map
• map_id
• project_nid
• project_name
• component_name
• package_namespace
• category
• 'indexes' => array('project_nid' => array('project_nid'),
  'project_component_category' => ['project_name', 'component_name', 'category'], ),

My guess at the existing records:

• project_name: operations
• component_name: site
• package_namespace: site
• project_name: operations
• component_name: site_manager
• package_namespace: site_manager
• project_name: operations
• component_name: operations_ui
• package_namespace: operations_ui
• project_name: site
• component_name: site
• package_namespace: site-site
• project_name: site_manager
• component_name: site_manager
• package_namespace: site_manager-site_manager
• project_name: operations_ui
• component_name: operations_ui
• package_namespace: operations_ui-operations_ui

Proposed Solution

Update package_namespace based on project_name.

1. UPDATE {project_composer_namespace_map} SET package_namespace = 'site' WHERE project_name = 'site';
2. UPDATE {project_composer_namespace_map} SET package_namespace = 'site_manager' WHERE project_name = 'site_manager';
3. UPDATE {project_composer_namespace_map} SET package_namespace = 'operations_ui' WHERE project_name = 'operations_ui';

Since package_namespace is not unique, do we have to DELETE records for project_name = 'operations' at all?

Since this involves correcting the project types, #3377494: Change Operations to General Project → , this is more about correcting the composer metadata to match the correct project types than changing by-design behavior seen in 🐛 Inconsistent extension module machine name (doubled for composer) Active .

The basic work is done, I did use the queries as-is, along with deleting the data for operations. This allowed https://packagist.org/packages/drupal/operations to be created.

Automatically closed - issue fixed for 2 weeks with no activity.