[policy] Decide on Composer Package Names

Diff & Diff
Datetime & Datetime

Please help me: Drupal\Component\Datetime vs. Drupal\datetime, Drupal\Component\Diff vs. Drupal\diff
How is that causing conflicting namespaces?

Same question as #5. The issue summary doesn't explain what the practical issue is, or why it's critical.

The question is about composer package names, not code namespaces.

Yes, I think we are talking about package names :)

In the composer context we should clarify the meaning of the drupal vendor. Is it the whole community, only code from drupal.org or only code from drupal core? Currently there are already some packages of the drupal vendor. I'm not sure if we should (or even if it is possible to) restrict creation of "drupal/"-packages by anyone on packagist.

In the Drupal environment we have many concepts that can become a Composer package or are one already:

• A full Drupal project
• Drupal core and the Drupal core distribution
• Install profiles and Drupal distributions based on a install profile
• Drupal modules
• Drupal themes
• Drupal Drush extensions (like drush_language)
• 3rd party libraries

With the type property of a composer.json we already could technically distinguish the types of a package (see Composer installers).

The main problem we may get is, when a module or component of core (or an installation profile) might hold the same name as a contrib module. The diff component of D8 core would be named drupal/diff as well as the contrib module might be called drupal/diff. This is "only" a problem because we are thinking of "drupal/" as the overall vendor prefix.

I do not think we should have different vendor prefixes (or prefixed package names) for each different type of Drupal package (see list above). I think we should use different vendors for distinguishing the source of the code, whether it is a component from Drupal core, a Project hosted on drupal.org (module, theme, profile) or a third party library hosted on github. Because of this I think we should use vendor prefixes like this:

• drupal-core/: For components and modules used within drupal core and created by the drupal core team
• drupal-org/: For projects on drupal.org: any project that is available at http://drupal.org/project/[name] would have the name drupal-org/[name]. This could be achieved by a custom packagist we are already working on.
• [author]/: A author prefix should be used by anything that is not created by the drupal core team and is not hosted on drupal.org.

I ignored drupal/ for now on purpose, as that vendor is to unclear at the moment, but maybe should be a replacement for drupal-core once we decide on the approach.

With #1886820: Packagist for Drupal Projects we already have some work going on for autogenerating composer information for Drupal.org projects. So there will be no need to publish each drupal module and theme to packagist.org.

Added beta phase evaluation to summary.

Sorry for mixing things up.

While this might be relevant for quite some cases when people publish their modules, I don't see why this could block Drupal 8.0.x from being released ...
Beside from that I think it is certainly valid to discuss it!

We already have a natural separation of project types on Drupal.org, so I would think that we have a natural fit for that:

For example we have the following project types:
Distribution project (drupal-dist/*)
Drupal core (drupal/*)
Drupal.org project (drupal-org/*)
Module project (drupal-module/*)
Theme Engine project (drupal-theme-engine/*)
Theme project (drupal-theme/*)

It might be good to lump modules, theme engines, and theme projects all together into the same Composer vendor namespace since naturally modules and themes cannot share the same name. So maybe a drupal-contrib/* vendor namespace?

@davereid
Following that logic, perhaps drupal-extension/ for modules and themes?

As I understand, on Drupal.org projects share the same "namespace", so no project of one type can share the same name with a project of another type (on drupal.org). From that perspective, I do not think we need different vendors for those different project types. In composer we can distinguish those different types by using composer type in composer.json. Drupal-packagist could do that automagically for any project on d.o .

From my perspective the main task is how we distinguish Drupal projects (hosted on d.o, like modules, themes, core, ...) from code components used in and created for those projects, such as submodules, subthemes and PHP components. Most of them (look at all contribs) may never be released as separate packages. But anyways I think that the "author" of that code should be the first indication for the vendor name.

In terms of the Drupal core components we could think of the Drupal core team as the author for those. So drupal-core could be a vendor for code initially created for Drupal core, but with the goal of releasing it as a separate component. The same approach could be used for core themes, modules and profiles.

For Drupal contrib components, we should not have any conflicting situation, as names of submodules and subthemes should not conflict with other modules or themes. PHP Components that are created for contrib projects should not use any of the drupal vendors at all, IMHO, as those mostly are either tightly coupled to the module itself and are not reusable or they are reusable and should be included in the authors vendor.

So from my perspective adding drupal-core would highlight the drupal core contributions to the PHP world and would avoid disappearance in a maybe clutterin up drupal vendor.

Introducing a separate single vendor (like drupal-contrib) would be helpful for an auto-generating Drupal Packagist. But that would be something to discuss seperately, for a contrib guideline in terms of "Should I post my module to packagist.org?". If there is a working Drupal Packagist, that step might not be necessary.

"This is a critical issue becuase a package name policy should be established before Drupal 8's release to avoid naming conflicts now or in the future."

Sorry, I don't think so. To review the definition of critical:

Critical bugs include those that:

Render a system unusable and have no workaround.
Cause loss of data.
Expose security vulnerabilities.
Cause tests to fail in HEAD on the automated testing platform, since this blocks all other work.

I think it's fine to try and resolve this before release, but in the event we don't, things being named inconsistently is only mildly inconvenient, and would not block the release of Drupal 8.

I would call this issue "normal," but splitting the difference as "major."

I'd consider this as a critical part of the the d8 infrastructure, but let's fix better make sure it gets fixed instead of arguing about the priority.

I don't think we should add the project type to the vendor prefix, even it's part of the namespacing - that's not what the vendor prefix is made for. It should tell me the source of the package, not its type.

In the composer context we should clarify the meaning of the drupal vendor. Is it the whole community, only code from drupal.org or only code from drupal core?

I think we need to bring the existing concept of approved projects hosted on d.o. to composer - (regardless what exactly that means or not). Thus, I think we need a general vendor prefix for everything approved of d.o., while sandboxes shouldn't get that prefix.

Currently there are already some packages of the drupal vendor. I'm not sure if we should (or even if it is possible to) restrict creation of "drupal/"-packages by anyone on packagist.

I do not know, but that seems to be an important issue to me in order to be able to gain the same amount of trust into drupal/* (or whatever prefix will end up with) packages as there is for drupal projects. How does e.g. symfony handle this?

So from my perspective adding drupal-core would highlight the drupal core contributions to the PHP world and would avoid disappearance in a maybe clutterin up drupal vendor.

Yeah, regardless of the namespacing a drupal-core vendor would make sense to me as well as there is way different process and level of trust behind those packages imo.

PHP Components that are created for contrib projects should not use any of the drupal vendors at all, IMHO, as those mostly are either tightly coupled to the module itself and are not reusable or they are reusable and should be included in the authors vendor.

I'm not sure about that, e.g. if we'd manage to make Rules re-usable it's still a package authored by multiple contributors and not me alone. So then, there would be drupal/rules for the module and a component - why shouldn't that be drupal/rules-core as well? It's a component authored by the same people, so shouldn't be the vendor be the same?

Related, there is also no clarification the right package type for drush yet, see https://github.com/drush-ops/drush/issues/1132

Proposal:

drupal/* - Any module or theme or whatever from Drupal.org. (They already share a namespace due to Drupal's architecture, so no sense breaking them up.)
drupal-core/drupal - Drupal core itself, the whole shebang.
drupal-core/* - A Drupal core component (Plugins, Utility, Datetime, etc.)

That keeps the number of vendors down to just 2, clearly establishes drupal/* as "stuff that gets mirrored from Drupal.org", and drupal-core as the "core team owns this" vendor. It's also super easy for people to remember.

Non-Drupal-coupled components that are not part of core... should just be on Packagist themselves in their own vendor namespaces.

In Symfony's case, the "symfony" namespace is reserved for the Symfony Git repo (aka, Fabien owns it). Bundles (the Symfony framework equivalent of modules) are in whatever their author's vendor namespace is. Many are in the FOS (FriendsOfSymfony) namespace, but many are also in some random person's GitHub username vendor. I think for Drupal we want to keep the "collective ownership" approach and use drupal/* rather than Crell/*, webchick/*, fago/*, etc.

+1 on drupal and drupal-core for vendor names in #20.

Also, when it comes to sub-types, +1 on #10 using composer installers. The 'type' property already knows how to route these things as long as everyone requires composer/installers: https://github.com/composer/installers

Any architectural changes to Drupal can be upstream changes to composer/installers.

More complex installation requirements can be turned into composer plugins if needed. Probably not though.

Basically: If you think we need a complex system for naming things or organizing things, you're doing it wrong.

I'm +1 on the propsal of #20, but honestly I don't care much, IMHO its more important that we have a decision than what the decision is.

David: I'd first ask why those even exist. It seems a silly split to make.

Baring that, I'd note that the odds of us splitting a core *module* (rather than core *Component*) out to its own packagist package are extremely remote, unless we were to move all of Drupal to be built via Composer (which is not on the table for D8, but totally should be a D9 priority). Even then, it's a module so we may as well reuse the module vendor namespace: drupal/datetime, classes in \Drupal\datetime.

Debatable. I'm inclined to say that Drupal itself should be an exception, since drupal/drupal is dead simple to remember and consistent with many other projects. (symfony/symfony, guzzlephp/guzzlephp, etc.)

Looking at those files though... wha? If the intent is that the top level composer.json file is the "user editable" one, why would that have the name drupal/drupal? Shouldn't that be something project specific, or at least not the key Drupal name?

(Symfony's standard install project has a name of symfony/framework-standard-edition, and then symfony/symfony is a dependency.)

When we follow the current Drupal naming process for modules, themes, profiles/distributions, they are all unique (or should be) even if they are only a submodule or subtheme of a project. With this approach we could deal with "drupal/" as the vendor for all projects and subprojects being hosted on drupal.org, that share this unique namespace due of Drupal's extension approach. For example: everything that currently can be downloaded with drush dl ... or enabled with drush en ... can use the name "drupal/...". This also would include the "Drupal core distribution" being "drupal/drupal".

As "Components" are not part of this unique namespace those should be split into a separate vendor "drupal-core". The same should be for the D8 core and named "drupal-core/drupal" or "drupal-core/core".

Following that rule we would end up with "drupal/datetime" being the core module and "drupal-core/datetime" being the PHP component developed by the drupal core team.

This approach also should not be a problem for "drupal/views" as we can distinguish the source for contrib (D7) and core (D8) by the version. Therefore we even can provide the module as one package, pointing to contrib for D7 and pointing to a metapackage for D8.

I'm not sure about that, e.g. if we'd manage to make Rules re-usable it's still a package authored by multiple contributors and not me alone. So then, there would be drupal/rules for the module and a component - why shouldn't that be drupal/rules-core as well? It's a component authored by the same people, so shouldn't be the vendor be the same?

@fago: following this approach, submodules, -themes or -profiles could live in "drupal/". For separate non-Drupal-Components you could introduce "drupal-rules" for the Rules Team.

Following the "symfony/"-approach, "drupal-core" could be our "symfony/", that would highlight the Drupal core contributions. Using "drupal/" for the whole Community (projects provided on drupal.org) therefore can be seen as the trusted source for Drupal "extensions".

+1 for the most part.

For overlaps I'd suggest one of two options:

1. The d.o project wins, so that d.o/project/diff becomes drupal/diff, whereas Drupal\Component\Diff becomes drupal/component-diff, and in fact we'd need to just go ahead and always add the component- part to all components for consistency.
2. d.o contrib-flavored projects have a vendor of drupal-project, so we have drupal-project/diff and drupal/diff.

I kind of prefer the latter because drupal-project is a bit like saying 'contrib.' It's not Drupal, but an extra add-on type thing.

Either way, is workable, though.

If I were writing a library that was part of a contrib project, I'd put it on github and call it mile23/whatever, and then it would be a dependency of my contrib project, and thus avoid the namespace issue altogether.

I don't know who exactly needs to approve this; probably one of the committers. So pushing it onto their radar. Let's get a move on.

The latest proposal makes a lot of sense to me. Can we identify whihc page of the handbook we're going to document this and do we have any composer documentation in core code that needs an update?

I did not find any composer documentation in core, so no need for an update there.

As https://www.drupal.org/node/1353118 deals with PHP Namespaces only, we should not mix that up with a naming convention for composer. I would create a separate Page "Composer package naming convetion" (with "Coding Standards" being the parent) for review now.

I created the documentation page on https://www.drupal.org/node/2471927.

As I added some text (e.g to try to clarify the "submodule"-situation), this needs a review again.

With #2211633: Provide a composer.json file for Drupal\Component\Plugin already landing, we actually need a patch in this issue. Therefore updating the title and adding the patch due to the convention discussed so far.

Looking at the patch, the core team maybe wants to go with the drupal-core vendor. This would be fine with our convention, as components are not forced to use drupal. For now I added the drupal/core- variant.

The syntax error of the composer.json is handled in #2472269: Fix syntax errors in Drupal\Component\Plugin's composer.json, Add test

Setting to RTBC as per #46.

Committed 3f95bfc and pushed to 8.0.x. Thanks!

Can someone make sure the relevant updates have been done to the handbook page.

Sorry, I don't know if the proposal was changed at some point or if this was already discussed above, but I always thought that we would use drupal/component-utility for Drupal\Component\Utility. Specifically because there is also a Drupal\Core\Utility. Now that drupal/core-utility is already taken there is no name that comes to mind for the latter.

Am I missing something?

Yep Drupal\Core\Utility will never be a separate thing in Composer.

Hmm... I was afraid that thar was going to be the answer. That's a little bit disappointing.

...but still yay for this change in general.

And thanks for the clarification!

To all whom are subscribed to follow this issue:

The Docs page Composer package naming conventions references this issue as "WIP". However issue status is "Closed (fixed)". Can we remove those lines from the top of the docs page, maybe?